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A DTV Profile for Uncompressed High Speed Digital Interfaces 


1 Scope 

CTA-861 establishes protocols, requirements, and recommendations for the utilization of uncompressed 
digital interfaces by consumer electronics devices such as Digital Televisions (DTVs), digital cable, 
satellite or terrestrial set-top boxes (STBs), and related peripheral devices including, but not limited to 
DVD players/recorders, and other related Sources or Sinks. 

CTA-861 is applicable to a variety of standard DTV-related high-speed digital physical interfaces - such 
as Digital Visual Interface (DVI) 1.0 [4], Open LVDS Display Interface (LDI) [8], and High-Definition 
Multimedia Interface (HDMI) [71] specifications. Protocols, requirements, and recommendations that are 
defined include Video Formats and waveforms; colorimetry and quantization; transport of compressed 
and uncompressed, as well as Linear Pulse Code Modulation (L-PCM), audio; carriage of auxiliary data; 
and implementations of the Video Electronics Standards Association (VESA) Enhanced Extended Display 
Identification Data Standard (E-EDID) [9], which is used by Sinks to declare display capabilities and 
characteristics. 

CTA-861 adopters are strongly encouraged to implement High-bandwidth Digital Content Protection 
(HDCP) [3] content protection, defined by the Digital Content Protection, LLC (DCP) method, in order to 
be compatible with digital cable STBs as authorized by 47 C.F.R. § 76.602 [69] and 47 C.F.R. §76.640 
[70]. HDCP [3] permits viewing of high-value content that may be available from other video Sources in a 
home network. 

2 General 

2.1 References 

CTA-861 includes mechanisms that allow a digital video Source (such as a cable, satellite or terrestrial 
STB, digital VCR, or DVD player) to supply displayable, baseband, digital video to High Definition 
Television (HDTV) devices, as well as peripheral devices such as repeaters, switchers, and recorders, as 
defined in CTA Expands Definitions for Digital Television Products [64]. 

2.1.1 Normative References 

The following standards contain provisions that, through reference in this text, constitute normative 
provisions of this standard. At the time of publication, the editions indicated were valid. All standards are 
subject to revision. Users of this Standard are cautioned that a newer edition might or might not be 
compatible. 

2.1.1.1 Normative Reference List 

1. SMPTE ST 170:2004 (Archived 2010) Television - Composite Analog Video Signal - NTSC for 
Studio Applications 

2. SMPTE ST 274:2008 Television - 1920 x 1080 Image Sample Structure, Digital Representation and 
Digital Timing Reference Sequences for Multiple Picture Rates 

3. DCP, L.L.C., High-bandwidth Digital Content Protection System, Revision 1.1, June 9, 2003 

4. DDWG, Digital Visual Interface, Revision 1.0, April 2, 1999 

5. IEC 61966-2-4: Multimedia systems and equipment - Colour measurement and management - Part 2- 
4: Colour management - Extended-gamut YCC colour space for video applications, January 2006 

6. Recommendation ITU-R BT.601-5, Studio Encoding parameters of Digital Television for standard 4:3 
and wide-screen 16:9 aspect ratios, 1995 

7. Recommendation ITU-R BT.709-5, Parameter Values for the HDTV standards for production and 
International Programme Exchange, 2002 - Part 2: HDTV system with square pixel common image 
format - 3: Signal format 

8. Open LVDS Display Interface (Open LDI) Specification, Version 0.95, May 13, 1999 

9. VESA E-EDID™ Standard, VESA Enhanced Extended Display Identification Data Standard, Release 
A, Revision 1, February 9, 2000 — Defines EDID Structure Version 1, Revision 3 

10. VESA DDC/CI Standard, VESA Display Data Channel Command Interface (DDC/CI) Standard, 
Version 1.1, October 29, 2004 

11. ATSC Standard A/52:2012: Digital Audio Compression (AC-3, E-AC-3), December 17, 2012 
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12. IEC 60958-3 Digital Audio Interface - Part 3: Consumer Applications, First Edition, 1999 

13. IEC 61909, Audio recording - Minidisc system 

14. IEC 61937-3:2007 Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 3: Non-linear PCM bitstreams according to the AC-3 and enhanced AC-3 formats 

15. IEC 61937-4:2003 Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 4: Non-linear PCM bitstreams according to the MPEG audio formats 

16. IEC 61937-5:2006, Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 5: Non-linear PCM bitstreams according to the DTS (Digital Theater Systems) 
format(s) 

17. IEC 61937-6:2006 Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 6: Non-linear PCM bitstreams according to the MPEG-2 AAC and MPEG-4 AAC 
audio formats 

18. IEC 61937-7:2004, Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 7: Non-linear PCM bitstreams according to the ATRAC, ATRAC2/3 and ATRAC-X 
formats 

19. IEC 61937-8:2006, Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 8: Non-linear PCM bitstreams according to the Windows Media Audio (WMA) 
Professional format 

20. IEC 61937-9:2007 Digital audio - Interface for non-linear PCM encoded audio bitstreams applying 
IEC 60958 - Part 9: Non-linear PCM bitstreams according to the MAT format 

21. IEC 61937-11 Digital audio - Interface for non-linear PCM encoded audio bitstreams applying IEC 
60958 - Part 11: MPEG-4 AAC and its extensions in LATM/LOAS 

22. IEC 61937-12:2010, DIGITAL AUDIO - INTERFACE FOR NON-LINEAR PCM ENCODED AUDIO 
BITSTREAMS APPLYING IEC 60958 - Part 12: Non-linear PCM bitstreams according to the DRA 
formats 

23. ISO/IEC 11172-3:1993, Information Technology - Coding of moving pictures and associated audio for 
digital storage media at up to about 1.5 Mbit/sec, Part 3: Audio, 1993 

24. ISO/IEC 13818-3, Information Technology - Generic coding of moving pictures and associated audio 
information, Part 3: Audio, Second Edition, 1998-04-15 

25. ISO/IEC 14496-3:2009, Information Technology - Coding of audio-visual objects - Part 3: Audio 

26. ISO/IEC 23003-1:2007 Information technology-- MPEG audio technologies -- Part 1: MPEG 
Surround with corrigendum 1 (February 2008) 

27. DVD Forum, DVD Specifications for Read-Only Disc, Part 4, Audio Specifications, Version 1.0, 
Meridian Lossless Packing 

28. SCTE 127:2007, Carriage of Vertical Blanking Interval (VBI) Data in North American Digital Television 
Bitstreams 

29. Microsoft, WMA Pro Decoder Specification: An Overview of Windows Media Audio Professional 
decoder 

30. CTA-770.2-D R-2012, Standard Definition TV Analog Component Video Interface 

31. CTA-770.3-E, High Definition TV Analog Component Video Interface 

32. IEC 61966-2-5, Multimedia systems and equipment - Colour measurement and management - Part 2- 
5: Colour management - Optional RGB colour space - opRGB 

33. IEC 61966-2-1:1999, Multimedia systems and equipment - Colour measurement and management - 
Part 2-1: Colour management - Default RGB colour space - sRGB 

34. IEC 61966-2-1/Amendment 1:2003 Multimedia systems and equipment - Colour measurement and 
management - Part 2-1: Colour management - Default RGB colour space - sRGB 

35. SMPTE ST 2016-1:2009 Format for Active Format Description and Bar Data 

36. ETSI TS 102 114, DTS Coherent Acoustics; Core and Extension with Additional Profiles 

37. ANSI INCITS 4-1986 (R2002) Coded Character Sets - 7-Bit American National Standard Code for 
Information Interchange (7-Bit ASCII), Table 8 

38. GB/T 22726-2008, Specification for multichannel digital audio coding technology 

39. Recommendation ITU-R BT.2020 (08/2012) Parameter values for ultra-high definition television 
systems for production and international programme exchange 

40. SMPTE ST 2084:2014, High Dynamic Range Electro-Optical Transfer Function of Mastering 
Reference Displays 
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41. SMPTE ST 2086:2014, Mastering Display Color Volume Metadata Supporting High Luminance and 
Wide Color Gamut Images 

42. ISO/IEC 62574, Audio, video and multimedia systems - General channel assignment of multichannel 
audio 

43. ISO/IEC 23008-3, Information technology -- High efficiency coding and media delivery in 
heterogeneous environments -- Part 3: 3D audio 

44. ISO/IEC 60958 Digital audio interface 

45. ETSI TS 103 190 VI. 1.1 (2014-04) Digital Audio Compression (AC-4) Standard 

46. IEC 61937-13: Digital audio - Interface for non-linear PCM encoded audio bitstreams applying IEC 
60958 - Part 13: MPEG-H 3D Audio 

47. IEC 61937-14: Digital audio - Interface for non-linear PCM encoded audio bitstreams applying IEC 
60958 - Part 14: Non-linear PCM bitstreams according to the AC-4 format 

48. IEC 60958-3 Digital Audio Interface - Part 3: Consumer Applications, First Edition, 1999 

49. VESA E-EDID™ Standard, VESA Enhanced Extended Display Identification Data Standard, Release 
A, Revision 1, February 9, 2000 

50. Recommendation ITU-R BT.2100-0 (07/2016) Image parameter values for high dynamic range 
television for use in production and international programme exchange 

51. SMPTE RP 431-2:2011 "D-Cinema Quality - Reference Projector and Environment” 

52. SMPTE EG 432-1:2010 "Digital Source Processing — Color Processing for D-Cinema” 

53. ETSI TS 103 433, 2016, High-Performance Single Layer Directly Standard Dynamic Range (SDR) 
Compatible High Dynamic Range (HDR) System for use in Consumer Electronics devices (SL-HDR1) 

54. Recommendation ITU-T H.264 (02/2016): Advanced video coding 

55. Recommendation ITU-T H.265 (04/2015): High efficiency video coding 

56. SMPTE ST 2094-1:2016: Dynamic Metadata for Color Volume Transform - Core Components 

57. SMPTE ST 2094-10:2016: Dynamic Metadata for Color Volume Transform - Application #1 

58. SMPTE ST 2094-40:2016: Dynamic Metadata for Color Volume Transform - Application #4 

59. Recommendation ITU-T T.35 Procedure for the allocation of ITU-T defined codes for non-standard 
facilities 


2.1.1.2 Normative Reference Acquisition 

ANSI Standards 

• American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036; Phone 
212-642-4900; Fax 212-398-0023; Internet http://www.ansi.org 

ANSI/CTA Standards 

• Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood, CO USA 
80112-5776; Phone 800-854-7179; Fax 303-397-2740; Internet qlobal.ihs.com ; Email 
qlobal@ihs.com 

DDWG 

• Contact Digital Display Working Group (DDWG); Attn: DDWG Administrator; M/S JF3-361; 2111 NE 
25th Avenue, Hillsboro, OR 97124-5961, USA; Fax: 503-264-5959; Internet http://www.ddwq.org ; 
Email ddwq.if@intel.com 

DTS 

• DTS, Inc., 5220 Las Virgenes Rd, Calabasas, CA 91302, U.S.A.; Phone (+1) 818 - 436-1000; 
Internet: dts.com/contact-us 

DVD Forum 

• Office of Secretary, DVD FORUM, Daimon Urbanist Bldg. 6F, 2-3-6 Shibadaimon, Minato-ku, Tokyo 
105-0012, Japan ; Phone +81 35 777 2881; Fax +81 35 777 2882; Internet http://www.dvdforum.org 

ETSI 

• European Telecommunications Standards Institute, 650, route des Lucioles, 06921 Sophia-Antipolis 
Cedex, France ; Phone +33 (0)4 92 94 42 00 ; Fax +33 (0)4 93 65 47 16 ; Internet http://www.etsi.org 
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GB/T Standards 

• Standardization Administration of the People's Republic of China (SAC), No.9 Madian Donglu 
Haidian District Beijing 100088,china; Phone +86 10 8226 2609; Fax +86 10 8226 0684; Internet 
http://www.sac.qov.cn/ ; E-mail webmaster@sac.qov.cn 


DCP 

• Digital Content Protection, L.L.C., c/o Intel Corporation, Stephen Balogh, JF2-55; 2111 NE 25th Ave; 
Hillsboro, OR 97124; Email info@diqital-cp.com ; Internet http://www.diqital-cp.com/home or 
http://www.diqital-cp.com 

ISO/IEC Standards 

• International Electrotechnical Commission, 3, rue de Varembe, PO Box 131, CH-1211 Geneva 20, 
Switzerland. Telephone +41 22 919 02 11; Telefax +41 22 919 03 00; Web: www.iec.ch ; Email: 
inmail@iec.ch 

ITU Standards 

• International Telecommunications Union, Place des Nations, CH-1211 Geneva 20, Switzerland; 
Phone +41 22 730 5111; Fax +41 22 733 7256; Internet http://www.itu.int/publications/default.aspx ; 
Email itumail@itu.int 

Microsoft Windows Media Licensing Program 

• Microsoft Windows Media Licensing Program, 1, Microsoft Way, Redmond, WA 98052, USA; Internet 
http://www.microsoft.com/windows/windowsmedia/licensinq/default.mspx ; Email 

wmla@microsoft.com 

OpenLDI 

• Contact National Semiconductor: Internet http://www.national.com/appinfo/fpd 
SMPTE Standards 

• Society of Motion Picture and Television Engineers, 3 Barker Ave., 5th Floor, White Plains, NY 
10601; Phone 914-761-1100; Fax 914-761-3115; Internet http://www.smpte.org 

VESA Standards 

• Contact Video Electronics Standards Association, 39899 Balentine Dr., Suite 125, Newark, CA 
94560, USA; Phone 510-651-5122; Internet http://www.vesa.org 


2.1.2 Informative References 

The following documents contain information that is useful in understanding this standard. At the time of 
publication, the editions indicated were valid. 

2.1.2.1 Informative Document List 

60. SMPTE ST 293:2003 (Archived 2010) Television - 720 x 483 Active Line at 59.94-Hz Progressive 
Scan Production - Digital Representation 

61. SMPTE ST 296:2012 1280 x 720 Progressive Image 4:2:2 and 4:4:4 Sample Structure - Analog and 
Digital Representation and Analog Interface 

62. SMPTE ST 125:1995 Television - Component Video Signal 4:2:2 - Bit-Parallel Digital Interface 

63. SMPTE ST 2035:2009 Audio Channel Assignments for Digital Television Recorders (DTRs) 

64. CTA Press Release; CTA Expands Definitions for Digital Television Products; August 31,2000 

65. CTA-608-D, Line 21 Data Service, May 2007 

66. CTA-708-C, Digital Television (DTV) Closed Captioning, July, 2006 

67. CTA-CEB16-A, Automatic Format Description (AFD) and Bar Data Recommended Practice, July, 
2012 

68. ETSI TS 101 154 vl .7.1, Digital Video Broadcasting (DVB); Implementation guidelines for the use of 
Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream 
(Annex B), June 14, 2005 
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69. FCC Regulations, Part 76, Cable Television Service, 47 C.F.R. §76.602 

70. FCC Regulations, Part 76, Cable Television Service, 47 C.F.R. §76.640 

71. HDMI, High-Definition Multimedia Interface Specification, Version 1.4b, October 11,2011 

72. IEC 60958-1 Digital Audio Interface - Part 1: General, First Edition, 1999 

73. ISO/IEC 13818-2:2000, Information technology -- Generic coding of moving pictures and associated 
audio information: Video 

74. Recommendation ITU-R BT.1700, Characteristics of composite video signals for conventional 
analogue television systems, 2005 

75. Recommendation ITU-R BT.656-4, Interfaces for Digital Component Video Signals in 525-line and 
625-line Television Systems Operating at the 4:2:2 Level of Recommendation, 1998 

76. Recommendation ITU-R BT.711-1, Synchronizing Reference Signals for the Component Digital 
Studio, 1992 

77. Recommendation ITU-R BT.1358, Studio Parameters of 625 and 525 Line Progressive Scan 
Television Systems, 1998 

78. VESA Coordinated Video Timings (CVT), Version 1.1, September 10, 2003 

79. VESA DI-EXT, Display Information Extension Block (DI-EXT™) for E-EDID, Release A, August 21, 
2001 

80. VESA E-EDID™ Implementation Guide, VESA Enhanced Extended Display Identification Data— 
Implementation Guide, Version 1.0, June 4, 2001— Provides support for VESA E-EDID™ Standard, 
VESA Enhanced Extended Display Identification Data Standard, Release A, Revision 1, February 9, 
2000 

81. VESA GTF Standard, VESA Generalized Timing Formula Standard, Version 1.1, September 2, 1999. 

82. ATRAC Audio Format Specifications for CTA-861 

83. VESA Coordinated Video Timing Generator, Revision 1.1, April 9, 2003 

84. VESA E-EDID™ Verification Guide, VESA Enhanced Extended Display Identification Data 
Verification Guide, Release A, March 27, 2007 — Provides support for VESA E-EDID™ Standard, 
VESA Enhanced Extended Display Identification Data Standard, Release A, Revision 2, September 
25,2006 

85. VESA GTF Spreadsheet, “VESA Generalized Timing Formula (GTF) Spreadsheet, Version 1, 
Revision 1.0, January 5, 1997 

86. VESA Monitor Timing Specifications, VESA and Industry Standards and Guidelines for Computer 
Display Monitor Timing (DMT), Version 1.0, Revision 11, Adoption Date: May 1, 2007 

87. VESA VTB-EXT, VESA Video Timing Block Extension Data Standard, Release A, November 24, 
2003 

88. AS 4933.1-2005, Digital television - Requirements for receivers - Part 1: VHF/UHF DVB-T television 
broadcasts, May 3, 2005 

89. [RESERVED! 

90. Unified Extensible Firmware Interface Forum - PNP ID Request Email aswq-chair@uefi.org 
Internet: http://www.uefi.org/PNP ACPI Registry 

91. Royal Philips Electronics and Sony Corporation, Super Audio CD System Description, Version 2.0 

92. IEEE Registration Authority 

93. IEC 61937-2:2007, Interface for non-linear PCM encoded audio bitstreams applying IEC 60958 - Part 
2: Burst-info 

94. SMPTE RP 40:2003 Specifications for 35-mm Projector Alignment and Screen Image Quality Test 
Film 

95. SMPTE RP 91:2002 Specifications for 70-mm Projector Alignment and Screen Image Quality Test 
Film (R2007) 

96. BDA, Blu-ray Disc Read-Only Format, Part 3 : Audio Visual Basic Specifications, Version 2.3 

97. SMPTE RP 202:2008 Video Alignment for Compression Coding 

98. VESA Enhanced Display Data Channel (E-DDC™) Standard, Version 1.2, December 26, 2007 

99. VESA Display Transfer Characteristic Data Block Standard, Version 1.0; August 31,2006 

100. VESA Display Device Data Block (DDDB) Standard, Version 1; September 25, 2006 

101. VESA Video Timing Block Extension Data Standard, Release A, November 24, 2003 

102. SMPTE ST 2036-1:2009 Ultra High Definition Television - Image Parameter Values for Program 
Production 
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103. SMPTE ST 2048-1:2011 2048 x 1080 and 4096 x 2160 Digital Cinematography Production 
Image Formats FS/709 

104. Blu-ray Disc Association, “System Description Blu-ray Disc Read-Only Format Part 3, Audio 
Visual Basic Specifications Version 3.1”, December 2015 

105. Rec. ITU-R BS.2051-0 (02/14) ‘Advanced sound system for programme production’ 


2.1.2.2 Informative Document Acquisition 

AS 

• SAI Global Limited, Business Publishing, GPO Box 5420, Sydney NSW 2001. Phone +61 2 8206 
6010; Fax+61 28 206 6020; Internet http://www.saiqlobal.com/shop 

BDA Standards 

• Blu-ray Disc Association (BDA), Blu-ray Disc Association 10 Universal City Plaza, T-100 Universal 
City CA 91608; Fax +1-818-301-1893; Internet http://www.blu-raydisc.com/index.htm ; E-mail 
membership@bdamail.com 

CTA Standards 

• Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood, CO USA 
80112-5776; Phone 800-854-7179; Fax 303-397-2740; Internet qlobal.ihs.com ; Email 
qlobal@ihs.com 

ETSI 

• European Telecommunications Standards Institute, 650, route des Lucioles, 06921 Sophia-Antipolis Cedex, 
France ; Phone +33 (0)4 92 94 42 00 ; Fax +33 (0)4 93 65 47 16 ; Internet http://www.etsi.org 

FCC 

• FCC Regulations, U.S. Government Printing Office, Washington, D.C. 20401; Internet 
http://www. access. gpo.qov/cqi-bin/cfrassemble.cqi?title=199847 

HDMI 

• HDMI Licensing, LLC, 1140 E. Arques Avenue, Suite 100, Sunnyvale, CA 94085 ; Internet 
http://www.hdmi.org 

IEEE Registration Authority 

• Institute of Electrical and Electronic Engineers, Inc., IEEE Registration Authority c/o IEEE Standards 
Association, 445 Hoes Lane, Piscataway, NJ 08855-1331; Internet 
http://standards.ieee.org/reqauth/oui/index.shtml 

ITU Standards 

• International Telecommunications Union, Place des Nations, CH-1211 Geneva 20, Switzerland; 

Phone +41 22 730 5111; Fax +41 22 733 7256; Internet http://www.itu.int/publications/default.aspx ; 

Email itumail@itu.int 

Philips 

• Philips Intellectual Property & Standards; IP Support; Visiting address: High Tech Campus 44, 

5656AE Eindhoven, The Netherlands; Mail address: P.O. Box 220, 5600 AE Eindhoven, The 
Netherlands; Internet http://www.ip.philips.com ; E-Mail info.licensinq@philips.com 

SMPTE Standards 

• Society of Motion Picture & Television Engineers (SMPTE), 595 West Hartsdale Avenue, White 
Plains, NY 10607; Phone 914-761-1100; Fax 914-761-3115; Internet http://www.smpte.org ; Email 
smpte@smpte.org 
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Sony 

• ATRAC Audio Format Specifications for CTA-861 Sony Corporation Head Office, 1-7-1 Konan, 
Minato-ku, Tokyo, 108-0075, Japan; Email atrac-CTA@ip.sony.com 

VESA Standards 

• Contact Video Electronics Standards Association, 39899 Balentine Dr., Suite 125, Newark, CA 
94560, USA; Phone 510-651-5122; Internet http://www.vesa.org 


2.2 Definitions 

For the purposes of CTA-861, the following definitions apply. 

2160p —A progressive CE Video Format with VIC in the range 93 through 107 and having 2160 active 
vertical lines (Vactive) lines per Video Frame. 

Active Format Description (AFD) —A data structure that describes what portion of the Picture actually 
contains useful information (e.g., letterbox and pillarbox Bars are not considered useful information). It is 
a 4-bit field like that standardized in ETSI TS 101 154 [68], but whose exact meaning may depend on 
whether the data is delivered per ATSC/SCTE or ETSI standard. See Section 6.4 for details. Note that the 
use of the term “active” in this definition is not consistent with the use of this term in other portions of 
CTA-861 and most of the other documents referenced by CTA-861. 

Active Image —The useful portion of the image contained within a Picture. Active Image excludes 
letterbox and pillarbox Bars (see Annex N). 

Active Line —A Video Line occurring during the Vactive period(s) containing both Active Pixels and Blank 
Pixels. Active Pixels and Blank Pixels fill the Hactive and Hblank portions of these lines, respectively (see 
Annex N). 

Active Pixel —A Video Pixel that conveys Pixel Data (see Annex N). 

Auxiliary Video Information (AVI) —Additional information (defined in CTA-861) related to the video 
being sent from a Source to a Sink. 

A/V —Audio and Video. 

Bar Data —Data that enable computation of regions of the image that are outside of the Active Image 
within a Picture, for example areas of zero or uniform luminance (i.e., Bars). 

Bar Pixel - An Active Pixel that conveys a portion of a Bar (see Annex N). 

Bars —Region of the display screen that is being driven or scanned at either zero luminance or at a 
uniform luminance; or regions of a Picture that are intended to be driven (e.g., matrix addressed) or 
scanned (e.g., cathode ray tube (CRT)) at either zero luminance or at a uniform luminance. In other 
words, it is the portion of the Picture that does not contain useful information (see Annex N). 

Basic Audio —Uncompressed, two channel, digital audio. Exact parameters are determined by the 
interface specification used with CTA-861 (e.g., 2 channel IEC 60958-3 [12] L-PCM, 32, 44.1, and 48 kHz 
sampling rates, 16 bits/sample). 

Blank Pixel —A Video Pixel that carries data other than Pixel Data (see Annex N). 

Blanking Line —A Video Line occurring during Vblank period(s) containing only Blank Pixels. Blank 
Pixels fill both Hactive and Hblank portions of these lines (see Annex N). 

Byte —8 bits of data. 
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CE Video Format —Any Video Format listed in Table 1 except the 640x480p Video Format. 

CTA Extension —The E-EDID Standard [9] defines a VESA-assigned tag (0x02) that allows for an 
extension to be added with additional timing formats. 

Channel, Speaker - There is a direct relation between a Channel and a Speaker. Audio feeding into a 
Speaker is sent via a Channel. 

Coded Frame - A (compressed) signal representing a rectangular array of Coded Pixels containing an 
image that may, in whole or part, be eventually rendered onto a display. 

Coded Line - A horizontal line of Coded Pixels output by a video acquisition function (e.g., a 
decompressor or a camera aperture). 

Coded Pixel - The colored component samples of a single picture element (pixel) output by a video 
acquisition function (e.g., decompressor or a camera aperture). 

Color Component Sample —A value that conveys a portion of the total information about of a picture 
element (pixel). A Color Component Sample may be a red sample (R), green sample (G), blue sample 
(B), a luma sample (Y) or chroma sample (C). 

Component Depth —The number of bits used to represent a Color Component Sample. It is generally 
denoted as N. 

Compressed Audio —All audio formats other than L-PCM and One Bit Audio. 

Content Pixel - An Active Pixel that conveys a portion of the Active Image (see Annex N). 

Digital Television (DTV) —A device that receives, decodes, and presents audio and video material that 
has been transmitted in a compressed form. The device can be a single unit or it can be constructed from 
a number of individual components (e.g., a digital terrestrial STB and an analog television). 

Direct Stream Transfer (DST) — A lossless compression scheme for the Direct Stream Digital audio 
format. 

DTV —Defined in CTA-861 to be an HDTV or SDTV. A Sink can also be any combination of these terms. 
A DTV with an uncompressed video input is also considered a Sink. 

Dual-Aspect Ratio DTV —A DTV that simultaneously supports both Picture Aspect Ratios of a Video 
Format Timing (e.g., 720x480p). Listing both formats in the EDID data structure at the same time signifies 
simultaneous support. 

Dual-Aspect Ratio Timing —A Video Format Timing (e.g., 720x480p) that is available in both Picture 
Aspect Ratios (16:9 and 4:3) with no difference in the timing for the two formats. 

Electro-Optical Transfer Function (EOTF) - A mathematical function that describes the relationship 
between the luminance values input to a display device and the values output by the display. 

Full Range —R, G, B or Y Quantization Range that includes all code values. See Section 5.4. 

High Channel Count Audio (HCCA) - Channel based audio that can be presented in speaker 
configurations greater than 7.1. For CTA-861, HCCA is limited to 32 channels. 

High Definition Television (HDTV) —A DTV capable of displaying a 1920x1080i or 1280x720p Video 
Format in 16:9 Picture Aspect Ratio. See Section 3.2. 
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High Definition (HD) —A CE Video Format that, inclusively, has 720 to 1080 active vertical lines (Vactive) 
lines per Video Frame. 

High Dynamic Range (HDR)- In a display device, the range of luminance levels that exceed 
conventional display system capabilities. 

InfoFrame —A data transfer structure for sending miscellaneous information from a Source 
to a Sink over a CTA-861 interface. Various InfoFrames are described in Section 6. 

Interface Development Organization (IDO) - The organization (e.g., HDMI LLC, HDMI Forum, VESA) 
responsible for the CTA-861 implementation that is present. 

Interface VSIF - One or more VSIF(s) defined by the IDO. 

IRE Unit - A percentage of reference white with respect to black (i.e., blanking level). Reference white is 
assigned a value of 100, blanking a value of 0. 

IT Video Format —Any Video Format that is not a CE Video Format. Specifically, any Video Format not 
listed in Table 1 plus the 640x480p Video Format. 

Limited Range —R, G, B or Y Quantization Range that excludes some code values at the extremes. See 
Section 5.4. 

Multi-channel Audio —Digital audio with more than two channels, for example, L-PCM or AC-3. 

Native Display Device Aspect Ratio —Ratio of maximum width to height dimension of the addressable 
portion of a physical display device screen, which is indicated in the EDID version 1, revision 3 block’s 
“Max Horizontal Image Size” and “Max Vertical Image Size” fields. 

Native Video Format —A Video Format with Native Pixel Layout and scanning method that the display 
device accepts and displays without any internal scaling, de-interlacing, interlacing or frame rate 
conversion. 

Native Pixel Layout —The exact number of horizontal pixels and vertical lines (or pixel mapping) that 
matches the physical structure of the display device. 

Object Based Audio (OBA) - In Object Based Audio, each sound is expressed as an Object with a 3D 
position in space rather than a discrete number of channels or loudspeakers. 

One Bit Audio —1-bit Sigma-Delta (Delta-Sigma) modulated signal stream. 

opRGB —The optional RGB color space defined in IEC 61966-2-5 [32]. 

opYCCeoi—The luma-chroma-chroma (YCC) color space defined in Annex A of IEC 61966-2-5 [32]. The 
ITU-R BT.601 [6] color conversion matrix is used to transform RGB values to YCC values. 

Picture — An uncompressed video signal representing a rectangular array of pixels containing an image 
that may, in whole or part, be rendered onto a display. A Picture refers to the Pixel Data transferred in the 
uncompressed video signal during a single Video Frame. A Picture includes both the Active Image and 
Bars (see Annex N). 

Picture Aspect Ratio —Ratio of width to height dimension of the Picture as delivered across the 
uncompressed digital interface, including any top, bottom, or side Bars. Only four Picture Aspect Ratios 
are specified for this interface: 4:3, 16:9, 64:27, and 256:135 (see Annex N). 
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Picture Pixel —An single Active Pixel within a Picture Line containing a portion of either the Active Image 
or a Bar. 

Picture Line —The complete set of contiguous Active Pixels along a single Active Line, where each 
Active Pixel contains a portion of either the Active Image or a Bar. 

Pixel Data —Color Component Samples transmitted over the interface during a single Active Pixel. These 
samples may, but need not, completely define a single picture element (pixel). 

Preferred Picture Aspect Ratio —In a Dual-Aspect Ratio DTV, the preferred aspect ratio of a given 
Video Format Timing (e.g., 720x480p) is the aspect ratio of the first such timing listed in the EDID data 
structure (see Section 4.1). This would be the Picture Aspect Ratio that would be displayed if a DTV were 
to receive a Video Format Timing with no accompanying Picture Aspect Ratio information (i.e., no AVI 
sent from Source). 

Preferred Video Format —The Video Format that a display manufacturer determines provides optimum 
image. 


NOTE—Source implementers are encouraged to review Section 7.2.3 for related guidance. 

Quantization Range —The range of code values used to represent the color components of Active Pixels 
when transitioning between color extremes (e.g., black to white). 

RGB —A general representation of an analog or digital component video signal, where R represents the 
red color, G represents green, and B represents blue; and each component is sampled at a uniform rate 
(4:4:4). For the purpose of CTA-861, the signal is digital. 

Sink —A device, which receives an uncompressed A/V signal. 

Source —A device, which generates an uncompressed A/V signal. 

Source Pass-through Mode —A mode supported by some media-based Sources, wherein 
decompressed video passes directly (in its original format) to a Sink without interlacing, deinterlacing, 
scaling, or frame rate conversion. 

sRGB —The default RGB color space defined in IEC 61966-2-1 [33]. 

Standard Definition Television (SDTV) —A DTV capable of displaying 720x480i 1 or 720x576i video in at 
least one of two Picture Aspect Ratios, 16:9 or 4:3. 

Standard Definition (SD) —A CE Video Format that has less than 720 active vertical lines (Vactive) lines 
per Video Frame (e.g., 480 or 576 active vertical lines). 

sYCCeoi—The luma-chroma-chroma (YCC) color space defined in Annex F of IEC 61966-2- 
1/Amendment 1 [34]. The ITU-R BT.601 [6] color conversion matrix is used to transform RGB values to 
YCC values. sYCCeoi color space can represent colors outside of the sRGB color gamut. 

Total Image — The entire image area including both Active Image and letterbox Bars or pillarbox Bars. 
The Coded Frame, in the case of a video acquisition function, or Picture, in the case of a CTA-861 
interface (see Annex N). 

Uncompressed Audio —Linear Pulse Code Modulated (L-PCM) and One Bit Audio. 


1 Content is encoded as 704x480 or 720x483 
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Unique Active Pixel — A timing pattern, consisting of either fractional, single, or multiple contiguous 
Active Pixels, that effectively increases or lowers horizontal resolution (see Annex O). By splitting each 
Active Pixel into two Unique Active Pixels (e.g., using YCbCr 4:2:0 sampling), the effective horizontal 
resolution can be doubled. Alternately, Unique Active Pixels consisting of one or more contiguous Active 
Pixels having the same (systematically repeated) Pixel Data can be used to lower horizontal resolution. 

In this case, the number of Active Pixels in a Unique Active Pixel is equal to the pixel repetition factor 
(PR+1). 

Unique Content Pixel — A timing pattern consisting of one or more contiguous Content Pixels having the 
same (systematically repeated) Pixel Data. 

Video Field —The period from the leading (active) edge of one vertical sync (Vsync) pulse to the same 
edge of the next Vsync pulse or the timing pattern associated with that period. 

Video Format —A Video Format is sufficiently defined such that when it is received at the DTV, the Sink 
has enough information to properly display an image. Although it is generally acceptable to define a Video 
Format by specifying only a Video Timing and a Picture Aspect Ratio, a more complete definition requires 
additional information including a Color Space, a Quantization Range, and a Component Depth (N). 

Video Format Timing (or Video Timing) —The waveform associated with a Video Format. Note that a 
specific Video Format Timing may be associated with more than one Video Format (e.g., 720x480p 
formatted in the 4:3 Picture Aspect Ratio or a 720x480p formatted in the 16:9 Picture Aspect Ratio). 

Video Frame —The period (beginning and ending where the active edges of horizontal and vertical sync 
align) for vertical total lines to elapse or the repetitive timing pattern associated with that period. Interlaced 
timings have two Video Fields per Video Frame, while progressive timings have only one. Therefore, in 
the case of progressive timings, the terms “video field” and “video frame” are synonymous. 

Video Identification (ID) Code —An integer value used to identify a particular Video Format listed in 
Table 4. Tables 2 and 3 use Video Identification Codes to cross reference a particular Video Format with 
its exact Video Timing. 

Video Line —The period, lasting Htotal pixel clock periods, beginning and ending with the active edge of 
a horizontal sync pulse (Hsync). The term may also refer to a timing pattern that occurs during this period 
consisting of Htotal contiguous Video Pixels. 

Video Pixel —The period delimited by two sequential pixel clock active edges. The term may also refer to 
the portion of a timing pattern where the interface transfers one unit of data. The unit of data transferred 
may be related to a single picture element (pixel) or other information (e.g., Audio) and may convey the 
same information as the preceding Video Pixel. 

xvYCCeoi —The extended gamut luma-chroma-chroma (YCC) color space defined in IEC 61966-2-4 [5]. 
The ITU-R BT.601 [6] color conversion matrix is used by 61966-2-4 [5] to transform RGB values to YCC 
values. The extent of the gamut is device dependent. 

XVYCC 709 — The extended gamut luma-chroma-chroma (YCC) color space defined in IEC 61966-2-4 [5]. 
The ITU-R BT.709 [7] color conversion matrix is used by 61966-2-4 [5] to transform RGB values to YCC 
values. The extent of the gamut is device dependent. 

YCbCr —A general representation of a digital component video signal, where Y represents luminance, Cb 
represents the color blue, and Cr represents red; the color component may be sub-sampled at half the 
rate as luminance (4:2:2) or may be sampled at a uniform rate (4:4:4). For the purposes of CTA-861, it 
may be considered a digital representation of YPbPr. 
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2.3 Symbols and Abbreviations 

AAC Advanced Audio Coding 

ADB Audio Data Block 

AFD Active Format Description 

AMOL96 Automated Measurement of Lineups 96 (bits/field) 

ANSI American National Standards Institute 

ATRAC Adaptive T ransform Acoustic Coding 

A/V Audio/Video 

AR Aspect Ratio 

AV/C Audio/Video Control 

AVI Auxiliary Video Information 

BD Blu-Ray Disc 

BDA Blu-ray Disc Association 

CD Compact Disk 

CID IEEE Company Identifier 

CTA Consumer Electronics Association 

CTA Consumer T echnology Association 

CRT Cathode Ray Tube 

DAC Digital to Analog Converter 

DBS Direct Broadcast Satellite 

DCP Digital Content Protection 

DDWG Digital Display Working Group 

DMT Display Monitor Timing 

DRA Digital Rise Audio (used with the Blu-ray Disc Read-Only Format [96]) 

DSC Digital Still Camera 

DST Direct Stream Transfer 

DTD Detailed Timing Descriptor 

DTV Digital Television 

DVC Digital Video Camera 

DVD Digital Versatile Disk 

D-VHS Digital VHS 

DVI Digital Visual Interface 

E-DDC Enhanced Display Data Channel 

E-EDID Enhanced Extended Display Identification Data Standard 

ELB End of Left Bar 

EOTF Electro-optical Transfer Function 

ETB End of Top Bar 

EUI Extended Unique Identifier 

FFP Fractional Fixed Point 

HCCA High Channel Count Audio 

HDCP High-bandwidth Digital Content Protection 

HD DVD High Definition DVD 

HDD Hard Disk Drive 

HDMI High-Definition Multimedia Interface 

HDTV High Definition Television 

HD High Definition 

HDR High Dynamic Range 

HLG Hybrid Log-Gamma 

HPD Hot Plug Detect 

IDO Interface Development Organization 

IEC International Electrotechnical Commission 

IEEE Institute of Electrical and Electronics Engineers 

IFDB InfoFrame Data Block 

IRE Institute of Radio Engineers 

ISO International Organization for Standardization 
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ITU International Telecommunications Union 

LCD Liquid Crystal Display 

LDI LVDS Display Interface 

L-PCM Linear Pulse Code Modulation 

LSB Least Significant Bit 

LVDS Low Voltage Differential Signaling 

MAT MLP Audio Transport 

MaxCLL Maximum Content Light Level 

MaxFALL Maximum Frame-average Light Level 

MPEG Moving Picture Experts Group 

MSB Most Significant Bit 

NABTS North American Basic Teletext Specification 

OBA Object Based Audio 

OpenLDI Open LVDS Display Interface 

OUI Organizationally Unique Identifier (NOTE: CID may be used as an alternative) 

PES Packetized Elementary Stream 

PLP Primary Listening Position 

PMP Portable Media Player 

RCD Room Configuration Descriptor 

SACD Super Audio CD 

SADB Speaker Allocation Data Block 

SBB Start of Bottom Bar 

SDTV Standard Definition Television 

SD Standard Definition 

SMPTE Society of Motion Picture & Television Engineers 

SPM Speaker Presence Mask 

SRB Start of Right Bar 

STB Set-Top Box 

SVD Short Video Descriptor 

SVR Short Video Reference 

TVG2X TVGuide 2X (bitrate) 

VBI Vertical Blanking Interval 

VCDB Video Capability Data Block 

VCR Video Cassette Recorder 

VDB Video Data Block 

VESA Video Electronics Standards Association 

VFPDB Video Format Preference Data Block 

VIC Video Identification (ID) Code 

VSADB Vendor-Specific Audio Data Block 

VSDB Vendor-Specific Data Block 

VSIF Vendor-Specific InfoFrame 

VSVDB Vendor-Specific Video Data Block 

WMA Pro Windows Media Audio Professional 

Y420CMDB YCbCr 4:2:0 Capability Map Data Block 


Y420VDB YCbCr 4:2:0 Video Data Block 
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2.4 Compliance Notation 

As used in this document, “shall” denotes mandatory provisions of the standard. “Should” denotes a 
provision that is recommended but not mandatory. “May” denotes a feature whose presence does not 
preclude compliance and implementation of which is optional. “Optional” denotes items that may or may 
not be present in a compliant device. 


2.5 Hexadecimal Notation 

The characters Ox preceding numbers or letters A through F designate the following values as 
hexadecimal notation. 


2.6 HxV Video Timing Notation 

Video Timings are sometimes expressed using HxV notation (e.g., “720x480”), where H and V are equal 
to the number of Active Pixels per Active Line and the number of Active Lines per Video Frame, 
respectively. The H value is sometimes surrounded by parenthesis and preceded by the number of 
Unique Active Pixels. Examples include: “720(1440)x480” and "3840(1920)x2160". In the first example, a 
Unique Active Pixel is formed by systematically repeating the preceding Active Pixel PR-number of times 
such that the effective horizontal resolution is lower than the value indicated in the parentheses by a 
factor of 1/(PR+1) (see Table 1, Note 2 for details). In the second example, two Unique Active Pixels are 
derived from each Active Pixel (e.g., by using 4:2:0 sampling) such that the effective horizontal resolution 
is doubled. 

Video Timings may also be expressed using the HxV @ F notation (e.g., “720x576i @ 50 Hz “), where a 
value F is appended to denote field frequency. The value F also refers to the Video Frame rate when the 
letter to the right of the value V is a ‘p’. North American Video Timings usually have a slash 7’ in the name 
(e.g., “720x480i @ 59.94/60 Hz”) to delimit dual vertical frequencies. Here, the first vertical frequency is 
adjusted by a factor of exactly 1000/1001 (for NTSC broadcast compatibility) relative to the second (see 
Table 1, Note 3). 


2.7 Bit Naming Conventions 

The names of the individual bits of multi-bit data values are composed using a value’s mnemonic followed 
by a bit number. The significance of each bit is indicated by the bit number according to little-endian 
convention (i.e., bit number 0 is the least significant). For example, the quantization value is given the 
mnemonic ‘Q’, which is associated with two bits named ‘QT and ‘Q0’. When the value Q=2, bit Q1=1 and 
bit Q0=0. 

Future bits are a special case. These bits begin with the mnemonic ‘F’ followed by a bit number. In this 
case, bit numbers indicate location - not significance. Future bits shall be set to zero and ignored. 


2.8 ASCII Codes, Characters & Strings 

ASCII characters shall be encoded using either 7-bit or 8-bit codes as indicated. The least significant 7- 
bits shall encode characters according to ANSI INCITS [37], where ANSI INCITS bits bl through b7 are 
mapped to bits 0 through 6, respectively. In the case of 8-bit codes, the msb (bit 7) shall always be set to 
zero. 

3 Overview 

CTA-861 describes requirements for video Sources and Sinks that include an uncompressed, baseband, 
digital video interface. These requirements apply to any baseband digital video interface that makes use 
of VESA E-EDID (structures for discovery of supported Video Formats) [9] and supports 24-bit RGB. The 
60 Hz/59.94 Hz Video Timings are based on analog formats already standardized in CTA-770.2 [30] and 
CTA-770.3 [31]. A preferred physical/link interface is not specified in CTA-861. See the annexes on how 
to apply CTA-861 to the individual interfaces available at the time of this writing. Digital Visual Interface 
(DVI 1.0) [4] and OpenLDI 0.95 [8] can be used to enable minimal digital interface functionality. To take 
advantage of these enhancements, the physical interface also needs a way to transport CTA InfoFrames, 
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digital audio, and YCbCr pixels from the Source to the Sink. The High-Definition Multimedia Interface 
(HDMI) [71] is capable of taking advantage of these enhancements. 

Enhanced Extended Display Identification Data (E-EDID) was created by VESA to enable plug and play 
capabilities of Sinks. This data, which would be stored in the Sink, describes Video Formats that the Sink 
is capable of receiving and rendering. The information is supplied to the Source, over the interface, upon 
the request of the Source. The Source then chooses its output format, taking into account the format of 
the original video stream and the formats supported by the Sink. The Source (e.g., STB) is responsible for 
the format conversions necessary to supply video in an understandable form to the Sink. 

CTA-861 includes the Sink’s ability to describe other capabilities in the E-EDID - in addition to supported 
Video Formats (e.g., digital audio). In those cases, the same basic mechanism applies (i.e., the Source 
reads EDID data in the Sink to determine its capabilities and then the Source sends only audio and Video 
Formats the Sink is capable of receiving). 

The physical/link standards in Annex B, Annex C and Annex D do not support transport of closed 
captioning (CTA-608-C [65] and CTA-708-C [66]); therefore, the Source processes these elements. 
Specifically, if closed captioning is to be displayed, it is decoded by the Source, inserted into the video, 
and displayed as open captions. Similarly, if system Information, program information, events, service 
descriptors, etc. are displayed, related graphical information is inserted into the video by the Source. 
Control of closed captioning settings, programs, events, etc. is a feature of the Source, not supported by 
this interface and beyond the scope of CTA-861. 

Furthermore, content advisory user menus, settings, and blocking are accommodated in the Source, and 
are beyond the scope of CTA-861. 

3.1 General Video Format Requirements for Sources 

A Source shall support at least one of the following Video Timings: 

640x480p @ 59.94/60HZ 
720x480p @ 59.94/60HZ 
720x576p @ 50Hz 

A Source that accepts 60Hz Video Formats, and that supports HDTV capability, should support 720x480p 
@ 59.94/60Hz and 1280x720p @ 59.94/60Hz or 1920x1080i @ 59.94/60Hz Video Format Timings. 

A Source that accepts 50Hz Video Formats, and that supports HDTV capability, should support 720x576p 
@ 50Hz and 1280x720p @ 50Hz or 1920x1080i @ 50Hz Video Format Timings. 


3.2 General Video Format Requirements for Sinks 

A Sink that accepts 60Hz Video Formats shall support the 640x480p @ 59.94/60Hz and 720x480p @ 

59.94/60Hz Video Format Timings. 

A Sink that accepts 50Hz Video Formats shall support the 640x480p @ 59.94/60Hz and 720x576p @ 
50Hz Video Format Timings. 

A Sink that accepts 60Hz Video Formats, and that supports HDTV capability, shall support 1280x720p @ 
59.94/60Hz or 1920x1080i @ 59.94/60Hz Video Format Timings. 

A Sink that accepts 50Hz Video Formats, and that supports HDTV capability, shall support 1280x720p @ 
50Hz or 1920x1080i @ 50Hz Video Format Timings. 

A Sink that supports 640x480p @ 59.94/60Hz shall support video formatted in a 4:3 Picture Aspect Ratio, 
as described in Section 4.1, and coded with the default Component Depth, colorimetry, and Quantization 
Range for IT Video Timing as specified in Section 5.1, when receiving such timing. 
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A Sink that supports 720x480p @ 59.94/60Hz or 720x576p @ 50Hz should support video formatted in 
either 4:3 or 16:9 Picture Aspect Ratio, as described in Section 4.1, and coded with the default 
Component Depth, colorimetry, and Quantization Range for CE Video Timing as specified in Section 5.1, 
when receiving such timings. 


4 Video Formats and Waveform Timings 

CTA-861 interfaces transport uncompressed digital video using a variety of CE and IT Video Timings. 

This section describes the default IT 640x480 Video Timing as well as all of the standard CE Video 
Timings. The balance of IT timings are documented in the VESA DMT [86], GTF [81, 85], and VESA CVT 
[78, 83] standards. 

Throughout CTA-861, the term “Video Format Timing” does not include aspect ratio, whereas the term 
“Video Format” does encompass the aspect ratio. 

A Video Timing with a vertical frequency that is an integer multiple of 6.00 Hz (i.e., 24.00, 30.00, 60.00, 
120.00 or 240.00 Hz) is considered to be the same as a Video Timing with the equivalent detailed timing 
information but where the vertical frequency is adjusted by a factor of 1000/1001 (i.e., 24/1.001, 30/1.001, 
60/1.001, 120/1.001 or 240/1.001). That is, they are considered two versions of the same Video Timing 
but with slightly different pixel clock frequencies. Therefore, a DTV that declares it is capable of displaying 
a Video Timing with a vertical frequency that is either an integer multiple of 6 Hz or an integer multiple of 
6 Hz adjusted by a factor of 1000/1001 shall be capable of displaying both versions of the Video Timing. 

The additional low-resolution progressive Video Format Timings (1440x240p, 2880x240p, 1440x288p, 
and 2880x288p) consist of one of several frame formats. These frame formats differ only by one or two 
scan lines in the vertical blanking interval. For that reason, they are treated as the same Video Format 
with a slight variation in the parameters (i.e., handled in a way similar to the 59.94Hz/60Hz formats). For 
this reason, if a Sink declares support of one of these Video Formats of a specific Picture Aspect Ratio 
(through EDID), then it shall support all variations of that Video Format of the same Picture Aspect Ratio. 

The mandatory and optional formats defined in CTA-861 shall comply with the timing parameters in Table 
1 and Table 2. 

In Table 2, note that the Vfront, Vsync, and Vback values are defined in terms of Video Lines (see 
Section 2.2 “Video Line”). The reader is advised that the signals Hsync, Vsync, Data Enable, and Clock 
are encoded in an interface-specific manner. For details, see the specifications for DVI [4], OpenLDI [8] or 
HDMI [71]. 

Standard-definition Video Timings generally use negative vertical and horizontal sync, while high- 
definition Video Timings use positive. 

Lines are always numbered sequentially from 1 to Vtotal and match the line numbers found in the given 
reference standard. In the case of high-definition Video Timings, the leading-line of vertical sync in field 1 
is always line 1. In the case of standard-definition Video Timings, line 1 may coincide with the leading-line 
of vertical sync in field 1 or a line slightly before it. CTA-861 Video Timings are sometimes based on 
legacy 60Hz standard-definition television standards that have slightly larger Vactive values (e.g., 483- 
lines vs. 480-lines). Such Video Timings begin line numbering before the leading-line of vertical sync in 
field 1 - in order to keep line-numbers in alignment with the legacy standard. The “Ln” column in Table 2 
provides the line number of the leading-line of vertical sync in field 1 for each Video Timing code. See 
Annex L for examples. 

For progressive Video Timings and Field 1 of interlace Video Timings, the leading (active) edge of Hsync 
and Vsync transitions shall be perfectly aligned plus or minus zero pixel clocks. In Field 2 of interlace 
Video Timings, the alignment between the leading (active) edge of Hsync and Vsync transitions shall be 
precisely a half-line (Htotal/2) plus or minus zero pixel clocks. 
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Field 

Rate 5 









(kHz) 

(Hz) 

(MHz) 

VIC 

Hactive 

Vactive 

I/P 

Htotal 

Hblank 5 

Vtotal 

Vblank 5 

H Freq 5 

V Freq 4 

Pixel Freq 5 

Low 

60,65 

1280 

720 

Prog 

3300 

2020 

750 

30 

18.000 

24.000 3 

59.400 

61,66 

1280 

720 

Prog 

3960 

2680 

750 

30 

18.750 

25.000 

74.250 

62,67 

1280 

720 

Prog 

3300 

2020 

750 

30 

22.500 

30.000 3 

74.250 

108, 109 

1280 

720 

Prog 

2500 

1220 

750 

30 

36.000 

48.000 3 

90.000 

32,72 

1920 

1080 

Prog 

2750 

830 

1125 

45 

27.000 

24.000 3 

74.250 

33,73 

1920 

1080 

Prog 

2640 

720 

1125 

45 

28.125 

25.000 

74.250 

34,74 

1920 

1080 

Prog 

2200 

280 

1125 

45 

33.750 

30.000 3 

74.250 

111, 112 

1920 

1080 

Prog 

2750 

830 

1125 

45 

54.000 

48.000 3 

148.500 

79 

1680 

720 

Prog 

3300 

1620 

750 

30 

18.000 

24.000 3 

59.400 

80 

1680 

720 

Prog 

3168 

1488 

750 

30 

18.750 

25.000 

59.400 

81 

1680 

720 

Prog 

2640 

960 

750 

30 

22.500 

30.000 3 

59.400 

110 

1680 

720 

Prog 

2750 

1070 

750 

30 

36.000 

48.000 3 

99.000 

86 

2560 

1080 

Prog 

3750 

1190 

1100 

20 

26.400 

24.000 3 

99.000 

87 

2560 

1080 

Prog 

3200 

640 

1125 

45 

28.125 

25.000 

90.000 

88 

2560 

1080 

Prog 

3520 

960 

1125 

45 

33.750 

30.000 3 

118.800 

113 

2560 

1080 

Prog 

3750 

1190 

1100 

20 

52.800 

48.000 3 

198.000 

93,103 

3840 

2160 

Prog 

5500 

1660 

2250 

90 

54.000 

24.000 3 

297.000 

94,104 

3840 

2160 

Prog 

5280 

1440 

2250 

90 

56.250 

25.000 

297.000 

95,105 

3840 

2160 

Prog 

4400 

560 

2250 

90 

67.500 

30.000 3 

297.000 

114,116 

3840 

2160 

Prog 

5500 

1660 

2250 

90 

108.000 

48.000 3 

594.000 

98 

4096 

2160 

Prog 

5500 

1404 

2250 

90 

54.000 

24.000 3 

297.000 

99 

4096 

2160 

Prog 

5280 

1184 

2250 

90 

56.250 

25.000 

297.000 

100 

4096 

2160 

Prog 

4400 

304 

2250 

90 

67.500 

30.000 3 

297.000 

115 

4096 

2160 

Prog 

5500 

1404 

2250 

90 

108.000 

48.000 3 

594.000 

121 

5120 

2160 

Prog 

7500 

2380 

2200 

40 

52.800 

24.000 3 

396.000 

122 

5120 

2160 

Prog 

7200 

2080 

2200 

40 

55.000 

25.000 

396.000 

123 

5120 

2160 

Prog 

6000 

880 

2200 

40 

66.000 

30.000 3 

396.000 

124 

5120 

2160 

Prog 

6250 

1130 

2475 

315 

118.800 

48.000 3 

742.500 

194, 202 

7680 

4320 

Prog 

11000 

3320 

4500 

180 

108.000 

24.000 3 

1188.000 

195, 203 

7680 

4320 

Prog 

10800 

3120 

4400 

80 

110.000 

25.000 

1188.000 

196, 204 

7680 

4320 

Prog 

9000 

1320 

4400 

80 

132.000 

30.000 3 

1188.000 

197, 205 

7680 

4320 

Prog 

11000 

3320 

4500 

180 

216.000 

48.000 3 

2376.000 

210 

10240 

4320 

Prog 

12500 

2260 

4950 

630 

118.800 

24.000 3 

1485.000 

211 

10240 

4320 

Prog 

13500 

3260 

4400 

80 

110.000 

25.000 

1485.000 

212 

10240 

4320 

Prog 

11000 

760 

4500 

180 

135.000 

30.000 3 

1485.000 

213 

10240 

4320 

Prog 

12500 

2260 

4950 

630 

237.600 

48.000 3 

2970.000 


Table 1 Video Format Timings—Detailed Timing Information 
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Field 

Rate 5 









(kHz) 

(Hz) 

(MHz) 

VIC 

Hactive 

Vactive 

I/P 

Htotal 

Hblank 5 

Vtotal 

Vblank 5 

H Freq 5 

V Freq 4 

Pixel Freq 5 

50Hz 

17,18 

720 

576 

Prog 

864 

144 

625 

49 

31.250 

50.000 

27.000 

19,68 

1280 

720 

Prog 

1980 

700 

750 

30 

37.500 

50.000 

74.250 

20 

1920 

1080 

Int 

2640 

720 

1125 

22.5 1 

28.125 

50.000 

74.250 

21,22 

1440 2 

576 

Int 

1728 2 

288 

625 

24.5 1 

15.625 

50.000 

27.000 

23,24 

1440 2 

288 

Prog 

1728 2 

288 

312 

24 

15.625 

50.080 

27.000 

23,24 

1440 2 

288 

Prog 

1728 2 

288 

313 

25 

15.625 

49.920 

27.000 

23,24 

1440 2 

288 

Prog 

1728 2 

288 

314 

26 

15.625 

49.761 

27.000 

25,26 

2880 2 

576 

Int 

3456 2 

576 

625 

24.5 1 

15.625 

50.000 

54.000 

27,28 

2880 2 

288 

Prog 

3456 2 

576 

312 

24 

15.625 

50.080 

54.000 

27,28 

2880 2 

288 

Prog 

3456 2 

576 

313 

25 

15.625 

49.920 

54.000 

27,28 

2880 2 

288 

Prog 

3456 2 

576 

314 

26 

15.625 

49.761 

54.000 

29,30 

1440 2 

576 

Prog 

1728 2 

288 

625 

49 

31.250 

50.000 

54.000 

31,75 

1920 

1080 

Prog 

2640 

720 

1125 

45 

56.250 

50.000 

148.500 

37,38 

2880 2 

576 

Prog 

3456 2 

576 

625 

49 

31.250 

50.000 

108.000 

39 

1920 

1080 

Int 

2304 

384 

1250 

85 

31.250 

50.000 

72.000 

82 

1680 

720 

Prog 

2200 

520 

750 

30 

37.500 

50.000 

82.500 

89 

2560 

1080 

Prog 

3300 

740 

1125 

45 

56.250 

50.000 

185.625 

96,106 

3840 

2160 

Prog 

5280 

1440 

2250 

90 

112.500 

50.000 

594.000 

101 

4096 

2160 

Prog 

5280 

1184 

2250 

90 

112.500 

50.000 

594.000 

125 

5120 

2160 

Prog 

6600 

1480 

2250 

90 

112.500 

50.000 

742.500 

198, 206 

7680 

4320 

Prog 

10800 

3120 

4400 

80 

220.000 

50.000 

2376.000 

214 

10240 

4320 

Prog 

13500 

3260 

4400 

80 

220.000 

50.000 

2970.000 

CO 

N 

X 

o 

CD 

1 

640 

480 

Prog 

800 

160 

525 

45 

31.469 

59.940 3 

25.175 

2,3 

720 

480 

Prog 

858 

138 

525 

45 

31.469 

59.940 3 

27.000 

4,69 

1280 

720 

Prog 

1650 

370 

750 

30 

45.000 

60.000 3 

74.250 

5 

1920 

1080 

Int 

2200 

280 

1125 

22.5 1 

33.750 

60.000 3 

74.250 

6,7 

1440 2 

480 

Int 

1716 2 

276 

525 

22.5 1 

15.734 

59.940 3 

27.000 

8,9 

1440 2 

240 

Prog 

1716 2 

276 

262 

22 

15.734 

60.054 3 

27.000 

8,9 

1440 2 

240 

Prog 

1716 2 

276 

263 

23 

15.734 

59.826 3 

27.000 

10,11 

2880 2 

480 

Int 

3432 2 

552 

525 

22.5 1 

15.734 

59.940 3 

54.000 

12,13 

2880 2 

240 

Prog 

3432 2 

552 

262 

22 

15.734 

60.054 3 

54.000 

12,13 

2880 2 

240 

Prog 

3432 2 

552 

263 

23 

15.734 

59.826 3 

54.000 

14,15 

1440 2 

480 

Prog 

1716 2 

276 

525 

45 

31.469 

59.940 3 

54.000 

16,76 

1920 

1080 

Prog 

2200 

280 

1125 

45 

67.500 

60.000 3 

148.500 

35,36 

2880 2 

480 

Prog 

3432 2 

552 

525 

45 

31.469 

59.940 3 

108.000 

83 

1680 

720 

Prog 

2200 

520 

750 

30 

45.000 

60.000 3 

99.000 

90 

2560 

1080 

Prog 

3000 

440 

1100 

20 

66.000 

60.000 3 

198.000 

97,107 

3840 

2160 

Prog 

4400 

560 

2250 

90 

135.000 

60.000 3 

594.000 

102 

4096 

2160 

Prog 

4400 

304 

2250 

90 

135.000 

60.000 3 

594.000 

126 

5120 

2160 

Prog 

5500 

380 

2250 

90 

135.000 

60.000 3 

742.500 

199, 207 

7680 

4320 

Prog 

9000 

1320 

4400 

80 

264.000 

60.000 3 

2376.000 

215 

10240 

4320 

Prog 

11000 

760 

4500 

180 

270.000 

60.000 3 

2970.000 
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Field 









(kHz) 

(Hz) 

(MHz) 

Rate 4 5 

VIC 

Hactive 

Vactive 

I/P 

Htotal 

Hblank 5 

Vtotal 

Vblank 5 

H Freq 5 

V Freq 4 

Pixel Freq 5 


40 

1920 

1080 

Int 

2640 

720 

1125 

22.5 1 

56.250 

100.00 

148.500 


41,70 

1280 

720 

Prog 

1980 

700 

750 

30 

75.000 

100.00 

148.500 


42, 43 

720 

576 

Prog 

864 

144 

625 

49 

62.500 

100.00 

54.000 


44, 45 

1440 2 

576 

Int 

1728 2 

288 

625 

24.5 1 

31.250 

100.00 

54.000 


64,77 

1920 

1080 

Prog 

2640 

720 

1125 

45 

112.500 

100.00 

297.000 

X 

84 

1680 

720 

Prog 

2000 

320 

825 

105 

82.500 

100.00 

165.000 

O 

o 

91 

2560 

1080 

Prog 

2970 

410 

1250 

170 

125.000 

100.00 

371.250 


117, 119 

3840 

2160 

Prog 

5280 

1440 

2250 

90 

225.000 

100.00 

1188.000 


127 

5120 

2160 

Prog 

6600 

1480 

2250 

90 

225.000 

100.00 

1485.000 


200, 208 

7680 

4320 

Prog 

10560 

2880 

4500 

180 

450.000 

100.00 

4752.000 


216 

10240 

4320 

Prog 

13200 

2960 

4500 

180 

450.000 

100.00 

5940.000 


218 

4096 

2160 

Prog 

5280 

1184 

2250 

90 

225.000 

100.00 

1188.000 


46 

1920 

1080 

Int 

2200 

280 

1125 

22.5 1 

67.500 

120.00 3 

148.500 


47,71 

1280 

720 

Prog 

1650 

370 

750 

30 

90.000 

120.00 3 

148.500 


48, 49 

720 

480 

Prog 

858 

138 

525 

45 

62.937 

119.88 3 

54.000 


50, 51 

1440 2 

480 

Int 

1716 2 

276 

525 

22.5 1 

31.469 

119.88 3 

54.000 

CO 

63,78 

1920 

1080 

Prog 

2200 

280 

1125 

45 

135.000 

120.00 3 

297.000 

N 

X 

85 

1680 

720 

Prog 

2000 

320 

825 

105 

99.000 

120.00 3 

198.000 

o 

CM 

92 

2560 

1080 

Prog 

3300 

740 

1250 

170 

150.000 

120.00 3 

495.000 


118, 120 

3840 

2160 

Prog 

4400 

560 

2250 

90 

270.000 

120.00 3 

1188.000 


193 

5120 

2160 

Prog 

5500 

380 

2250 

90 

270.000 

120.00 3 

1485.000 


201, 209 

7680 

4320 

Prog 

8800 

1120 

4500 

180 

540.000 

120.00 3 

4752.000 


217 

10240 

4320 

Prog 

11000 

760 

4500 

180 

540.000 

120.00 3 

5940.000 


219 

4096 

2160 

Prog 

4400 

304 

2250 

90 

270.000 

120.00 3 

1188.000 

8 N 

52, 53 

720 

576 

Prog 

864 

144 

625 

49 

125.000 

200.00 

108.00 

O -r- 
CM - 1 - 

54, 55 

1440 2 

576 

Int 

1728 2 

288 

625 

24.5 1 

62.500 

200.00 

108.00 


56,57 

720 

480 

Prog 

858 

138 

525 

45 

125.874 

239.76 3 

108.000 

CM I 

58,59 

1440 2 

480 

Int 

1716 2 

276 

525 

22.5 1 

62.937 

239.76 3 

108.000 


1. Vblanking—Fractional values indicate that the number of Blanking Lines varies (see timing diagram for more details). 


2. The pixels for the 720(1440)x480i@59.94/60Hz, 720(1440)x240p@59.94/60Hz, 720(1440)x576i@50Hz, and 720(1440)x288p@50Hz 
Video Formats are double clocked to meet minimum speed requirements of the interface, thus FI active is shown as 1440, instead of 720. At 
higher field rates, these formats continue to be double clocked - even though double clocking is unnecessary. Each pixel of the 1440xN 
480p and 576p formats, as well as the 2880xN 480i, 240p, 480p, 576i, 288p, and 576p formats, is repeated a variable number of times. The 
repeat value is communicated using the AVI InfoFrames (see Section 6.4). 

3. A Video Timing with a vertical frequency that is an integer multiple of 6.00 Flz (i.e., 24.00, 30.00, 48.00, 60.00, 120.00 or 240.00 Hz) is 
considered to be the same as a Video Timing with the equivalent detailed timing information but where the vertical frequency is adjusted by 
a factor of 1000/1001 (i.e., 24/1.001, 30/1.001, 60/1.001, 120/1.001 or 240/1.001). That is, they are considered two versions of the same 
Video Timing but with slightly different pixel clock frequencies. The vertical frequencies of the 240p, 480p, and 480i Video Formats are 
typically adjusted by a factor of exactly 1000/1001 for NTSC video compatibility, while the 576p, 576i, and the HDTV Video Formats are not. 
The VESA DMT standard [86] specifies a ± 0.5% pixel clock frequency tolerance. Therefore, the nominally 25.175 MHz pixel clock 
frequency value given for Video Identification Code 1 may be adjusted to 25.2 MHz to obtain an exact 60 Hz vertical frequency. 

4. To avoid fractional frame rate conversions in Source and Sinks, Sources should use the exact vertical frequencies of 25.000 Hz, 50.000 
Hz, 100.000 Hz, 120.000 Hz, 200.000 Hz, and 240.000 Hz at 25 Hz, 50 Hz, 100 Hz, 120 Hz, 200 Hz, and 240 Hz, respectively. Likewise, 
Sources should use the exact vertical frequencies of (24 * 1000) / 1001 Hz, (30 * 1000) / 1001 Hz, (48 * 1000) / 1001 Hz, (60 * 1000) / 1001 
Hz, (120 * 1000) / 1001 Hz, and (240 * 1000) / 1001 Hz at 23.98 Hz, 29.97 Hz, 47.95 Hz, 59.94 Hz, 119.88 Hz, 239.76 Hz, respectively. 

5. Data in this column is provided for informational purposes only._ 


Table 1 Video Format Timings—Detailed Timing Information (continued) 
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Table 2 Video Format Timi 


CTA-861-G 


Vsync 

Vback 

co 

"o 

Q. 

> 

sz 

—1 

Reference 

Standard 

Notes 

5 

20 

P 

1 

SMPTE 296M [61] 

1,2, 25 

5 

20 

P 

1 

SMPTE 296M [61] 

1,2 

5 

20 

P 

1 

SMPTE 296M [61] 

1,2 

5 

20 

P 

1 

SMPTE 296M [61] 

1,2, 25 

5 

36 

P 

1 

SMPTE 274M [2] 

14 

5 

36 

P 

1 

SMPTE 274M [2] 

14 

5 

36 

P 

1 

SMPTE 274M [2] 

14 

5 

36 

P 

1 

SMPTE 274M [2] 

14 

5 

20 

P 

1 

SMPTE 296M [61] 

26 

5 

20 

P 

1 

SMPTE 296M [61] 

26 

5 

20 

P 

1 

SMPTE 296M [61] 

26 

5 

20 

P 

1 

SMPTE 296M [61] 

26 

5 

11 

P 

1 

SMPTE 274M [2] 

27 

5 

36 

P 

1 

SMPTE 274M [2] 

27 

5 

36 

P 

1 

SMPTE 274M [2] 

27 

5 

11 

P 

1 

SMPTE 274M [2] 

27 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 29 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 29 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 29 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 29 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 30 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 30 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 30 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 30 

10 

22 

P 

1 

SMPTE 274M [2] 

31 

10 

22 

P 

1 

SMPTE 274M [2] 

31 

10 

22 

P 

1 

SMPTE 274M [2] 

31 

10 

297 

P 

1 

SMPTE 274M [2] 

31 

20 

144 

P 

1 

SMPTE 274M [2] 


20 

44 

P 

1 

SMPTE 274M [2] 


20 

44 

P 

1 

SMPTE 274M [2] 


20 

144 

P 

1 

SMPTE 274M [2] 


20 

594 

P 

1 

SMPTE 274M [2] 

32 

20 

44 

P 

1 

SMPTE 274M [2] 

32 

20 

144 

P 

1 

SMPTE 274M [2] 

32 

20 

594 

P 

1 

SMPTE 274M [2] 

32 


;—Detailed Sync Information 






















































































































ZHOS Z H09 


CTA-861-G 


o 

> 

Ll. 

Hfront 

Hsync 

Hback 

o 

Q_ 

X 

Vfront 

Vsync 

Vback 

00 

~o 

Q- 

> 

C 

—1 

Reference 

Standard 

Notes 

17,18 

1 

12 

64 

68 

N 

5 

5 

39 

N 

1 

ITU-R BT.1358 [77] 


19,68 

2 

440 

40 

220 

P 

5 

5 

20 


1 

SMPTE 296M [61] 

1,2 


4 

528 

44 

148 

P 

2 

5 

15 


1 

SMPTE 274M [2] 

1,2 

21,22 

3 

24 

126 

138 

N 

2 

3 

19 

N 

1 

ITU-R BT.656 [75] 

6, 15 

23,24 

1 

24 

126 

138 

N 

222 

3 

19 

N 

1 

ITU-R BT.1358 [77] 

7, 14, 15, 19 

23,24 

1 

24 

126 

138 

N 

3 23 

3 

19 

N 

1 

ITU-R BT.1358 [77] 

7, 14, 15, 19 

23,24 

1 

24 

126 

138 

N 

424 

3 

19 

N 

1 

ITU-R BT.1358 [77] 

7, 14, 15, 19 

25,26 

3 

48 

252 

276 

N 

2 

3 

19 

N 

1 

ITU-R BT.656 [75] 17 

8, 13, 14 

27,28 

1 

48 

252 

276 

N 

222 

3 

19 

N 

1 

ITU-R BT.656 [75] 17 

7, 8, 12, 13,19 

27,28 

1 

48 

252 

276 

N 

3 23 

3 

19 

N 

1 

ITU-R BT.656 [75] 17 

7, 8, 12, 13,19 

27,28 

1 

48 

252 

276 

N 

424 

3 

19 

N 

1 

ITU-R BT.656 [75] 17 

7, 8, 12, 13,19 

29,30 

1 

24 

128 

136 

N 

5 

5 

39 

N 

1 

ITU-R BT.1358 [77] 

9, 10, 14 


2 

528 

44 

148 

P 

4 

5 

36 


1 

SMPTE 274M [2] 

14 

37,38 

1 

48 

256 

272 

N 

5 

5 

39 

N 

1 

ITU-R BT.1358 [77] 

9, 11 

39 

5 

32 

168 

184 


23 

5 

57 

N 

1 

AS 4933.1-2005 [88] 

5 

82 

2 

260 

40 

220 

P 

5 

5 

20 


1 

SMPTE 296M [61] 

1,2, 26 

89 

2 

548 

44 

148 

P 

4 

5 

36 


1 

SMPTE 274M [2] 

14, 27 


m 

1056 

88 

296 


8 

10 

72 


1 

SMPTE 274M [2] 

1,2, 29 


2 

968 

88 

128 


8 

10 

72 


1 

SMPTE 274M [2] 

1,2, 30 

125 

2 

1096 

88 

296 


8 

10 

72 


1 

SMPTE 274M [2] 

31 


m 

2352 

176 

592 


16 

20 

44 


1 

SMPTE 274M [2] 



2 

2492 

176 

592 


16 

20 

44 


1 

SMPTE 274M [2] 

32 

1 

1 

16 

96 

48 

N 

10 

2 

33 

N 

1 

VESA DMT [86] 

3, 4 

2,3 


16 

62 

60 

N 

9 

6 

30 

N 

7 

CTA-770.2 [30] 

2 

4,69 


110 

40 

220 

P 

5 

5 

20 

P 

1 

CTA-770.3 [31] 

1,2 

5 


88 

44 

148 

P 

2 

5 

15 

P 

1 

CTA-770.3 [31] 

1,2 

6,7 

3 

38 

124 

114 

N 

4 

3 

15 

N 

4 

CTA-770.2 [30] 

2, 15 

8,9 

1 

38 



N 

420 

3 

15 

N 

4 

CTA-770.2 [30] 17 

7, 14, 15, 19 

8,9 

1 

38 



N 

5 21 

3 

15 

N 

4 

CTA-770.2 [30] 17 

7, 14, 15, 19 


3 

76 

248 


N 

4 

3 

15 

N 

4 

CTA-770.2 [30] 17 

8, 13 


1 

76 



N 

420 

3 

15 

N 

4 

CTA-770.2 [30] 17 

7, 8, 13, 19 


1 

76 



N 

5 21 

3 

15 

N 

4 

CTA-770.2 [30] 17 

7, 8, 13, 19 


1 




N 

9 

6 

30 

N 

7 

CTA-770.2 [30] 

9, 10, 13, 14 


2 

88 

44 


P 

4 

5 

36 

P 

1 

SMPTE 274M [2] 

14 


1 

64 

248 


N 

9 

6 

30 

N 

7 

CTA-770.2 [30] 

9, 11 

83 

B 


40 


P 

5 

5 

20 

P 

1 

CTA-770.3[31] 

1,2, 26 

90 

2 


44 


P 

4 

5 

11 

P 

1 

SMPTE 274M [2] 

14, 27 


B 


88 


P 

8 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 29 

102 

2 

88 

88 


P 

8 

10 

72 

P 

1 

SMPTE 274M [2] 

1,2, 30 

126 

2 


88 


P 

8 

10 

72 

P 

1 

SMPTE 274M [2] 

31 


B 




P 

16 

20 

44 

P 

1 

SMPTE 274M [2] 


215 

2 




P 

16 

20 

144 

P 

1 

SMPTE 274M [2] 

32 
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_ 00 

"O CM 

® 3 
il £ 

o 

> 

iZ 

Hfront 

Hsync 

Hback 

o 

Q_ 

X 

Vfront 

Vsync 

Vback 

o 

Q. 

> 

C 

—I 

Reference 

Standard 

Notes 

100 Hz 

40 

4 

528 

44 

148 

P 

2 

5 

15 

P 

1 

SMPTE 274M [2] 



2 

440 

40 

220 

P 

5 

5 

20 

P 

1 

SMPTE 296M [61] 



1 

12 

64 

68 

N 

5 

5 

39 

N 

1 

ITU-R BT.1358 [77] 



3 

24 

126 

138 

N 

2 

3 

19 

N 

1 

ITU-R BT.656 [75] 

16 


2 

528 

44 

148 

P 

4 

5 

36 

P 

1 

SMPTE 274M [2] 


84 

2 

60 

40 

220 

P 

5 

5 

95 

P 

1 

SMPTE 296M [61] 

26 

91 

2 

218 

44 

148 

P 

4 

5 

161 

P 

1 

SMPTE 274M [2] 

27 


B 

1056 

88 

296 

P 

8 

10 


P 

1 

SMPTE 274M [2] 


127 

2 

1096 

88 

296 

P 

8 

10 


P 

1 

SMPTE 274M [2] 

31 


H 

2112 

176 

592 

D 

mm 



P 

1 

SMPTE 274M [2] 


216 

2 

2192 

176 

592 

p 

16 



P 

1 

SMPTE 274M [2] 

32 

218 

2 

800 

88 

296 

p 

8 

10 


P 

1 

SMPTE 274M [2] 


120 Hz 

46 

4 

88 

44 

148 

p 

2 

5 

15 

□ 

1 

SMPTE 274M [2] 



2 

110 

40 

220 

p 

5 

5 

20 

B 

1 

SMPTE 296M [61] 


48, 49 

1 

16 

62 

60 

N 

9 

6 

30 

N 

7 

CTA-770.2 [30] 



3 

38 

124 

114 

N 

4 


15 

Q 

4 

CTA-770.2 [30] 

16 

63,78 

2 

88 

44 

148 

P 

4 

5 

36 

B 

1 

SMPTE 274M [2] 


85 

2 

60 

40 

220 

P 

5 

5 

95 

B 

1 

SMPTE 296M [61] 

26 

92 

2 

548 

44 

148 

P 

4 

5 


p 

1 

SMPTE 274M [2] 

27 

118, 120 

2 

176 

88 

296 

P 

8 

10 


p 

1 

SMPTE 274M [2] 


193 

2 

164 

88 

128 

P 

8 

10 


p 

1 

SMPTE 274M [2] 

31 

201,209 

2 

352 

176 

592 

P 

16 

20 


p 

1 

SMPTE 274M [2] 


217 

2 

288 

176 

296 

P 

16 

20 


p 

1 

SMPTE 274M [2] 

32 

219 

2 

88 

88 

128 

P 

8 

10 


p 

1 

SMPTE 274M [2] 


200 

Hz 

52, 53 

1 

12 

64 

68 

N 

5 

5 

39 

N 

1 

ITU-R BT.1358 [77] 



3 

24 

126 

138 

N 



19 

N 

1 

ITU-R BT.656 [75] 

16 

240 

Hz 

56,57 

1 

16 

62 

60 

N 

9 

6 

30 

N 

7 

CTA-770.2 [30] 


58,59 

3 

38 

124 

114 

N 

D 



N 

4 

CTA-770.2 [30] 

16 


Notes: 


1. The reference standard uses tri-level sync, while CTA-861 uses bi-level. Bi-level sync timing is accomplished using the 
second half of the reference standard’s tri-level sync, defining the actual sync time to be the rising edge of that pulse. 

2. The reference standard uses a composite sync while CTA-861 uses separate sync signals, thus eliminating the need for 
serrations during vertical sync. 

3. VESA defines blanking as not including the border while CTA-861 includes the border within the blanking interval. 

4. Uses default IT color space, RGB components, and Full Range 8-bit color coding & quantization (see Section 5.1). 

5. Is specifically designed for use with 31.25 kHz constant horizontal rate cathode-ray tube televisions and has a total of 1250 
vertical lines - instead of the normal 1125 found in SMPTE 274 based timings. It has a frame, which is split into two unequal 
fields of 624.5 and 625.5 lines. The Video Format is specifically designed for use with special 31.25 kHz constant horizontal 
rate cathode-ray tube televisions and should be used with caution. Timing is similar to the 1250/50/2:1 system that described in 
Australian AS 4933.1-2005 standard [88], 































































CTA-861-G 


6. Same as the reference standard except for horizontal and vertical synchronization pulse durations, which are specified in 
ITU-R BT.711-1 [76] and ITU-R BT.1700 [74], Thus, the clock is 27 MHz. 

7. There are two or three Video Frame timings that differ only in the number of Blanking Lines in the vertical blanking interval of 
the frame. All are considered variations of the same Video Timing. 

8. Represents a superset of game console timings with variable repetition factors. Encompasses all of the following cases: 

a) 2880/10=288 pixels/line 

b) 2880/8=360 pixels/line 

c) 2880/7=411 pixels/line 

d) 2880/5=576 pixels/line 

e) 2880/4=720 pixels/line 

Typically has Bars on the left and right sides that are 160/n pixels wide, where n is the repetition factor. 

9. Represents a superset of timings with specific repetition factors that provide either additional bandwidth for carrying audio 
data or increased horizontal video resolution. 

10. Is a superset of Video Formats encompassing all of the following cases: 

a) 1440/2=720 pixels/line 

b) 1440/1=1440 pixels/line 

11. Is a superset of Video Formats encompassing all of the following cases: 

a) 2880/4=720 pixels/line 

b) 2880/2=1440 pixels/line 

c) 2880/1=2880 pixels/line 

12. The exact Video Timing depends upon the pixel repetition factor specified in the AVI InfoFrame. 

13. If this Video Timing is advertised in the EDID, the Sink shall have an interface capable of signaling pixel repetition via AVI 
InfoFrames (e.g., HDMI) and shall accept all listed pixel repetition factors. 

14. It is likely that non-HDMI Sources may not recognize this Video Format in a Detailed Timing Descriptor. 

15. Assumes the pixels are double-clocked to meet minimum clock speed requirements for the interface. 

16. Assumes the pixels are double-clocked. 

17. This is a “gaming” format. Progressive timing is obtained by removing the second field of the reference standard’s interlace 
timing. 

18. Hpol and Vpol stand for horizontal and vertical sync pulse polarity, respectively. The value ‘N’ signifies negative polarity, 
where the signal stays mostly high (at a logic ‘1’) and only pulses low (to a logic ‘0’) during the sync pulse. Likewise, the value 
P’ signifies positive polarity, where the signal stays mostly low (at a logic ‘0’) and only pulses high (to a logic ‘1’) during the 
sync pulse. 

19. Vfront varies as a function of Vtotal. 

20. This value applies when Vtotal is 262 lines. 

21. This value applies when Vtotal is 263 lines. 

22. This value applies when Vtotal is 312 lines. 

23. This value applies when Vtotal is 313 lines. 

24. This value applies when Vtotal is 314 lines. 

25. This Video Timing has been modified from the one listed in the reference standard. The reference standard specifies an 
odd Htotal greater than 4096, which is incompatible with legacy silicon. CTA-861 instead uses the referenced standard’s 
720p30 Video Timing with a reduced pixel clock frequency to obtain 24Hz. 
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CTA-861-G 


26. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 
been modified to provide Hactive of 1680 pixels needed to achieve a 64:27 Picture Aspect Ratio with approximately square 
(64:63) pixels. 

27. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 
been modified to provide Hactive of 2560 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 

28. Data in this column is provided for informational purposes only. 

29. Using UHDTV1 image sample structures and frame rates from SMPTE 2036-1:2009 [102], 

30. Using UHDTV1 image sample structures and frame rates from SMPTE 2048-1:2011 [103]. 

31. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 
been modified to provide Hactive of 5120 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 

32. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 

been modified to provide Hactive of 10240 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 


Table 2 Video Format Timings—Detailed Sync Information (continued) 
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Figure 3 General Interlaced Video Format Timing (Negative Sync) 
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Figure 4. General Interlaced Video Format Timing (Positive Sync) 
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Figure 5 Special Interlaced Video Format Timing (Even Vtotal) 
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4.1 Aspect Ratio 

A DTV should always indicate its native (physical) aspect ratio in the EDID version 1, revision 3 block’s 
“Max Horizontal Image Size” and “Max Vertical Image Size” fields even if the maximum image size is 
unknown or variable. Typically, the ratio of these two fields is 4:3, 16:9, or 64:27 - though this may not be 
true for some displays with non-standard aspect ratios. The Source should use these fields to determine 
the Native Display Device Aspect Ratio. 

The 480p, 480i, 240p, 576p, 576i, and 288p Video Formats are available in two different aspect ratios 
(4:3 and 16:9). The 720p, 1080p, and certain 2 2160p Video Formats are also available in two different 
aspect ratios (16:9 and 64:27). Video formats with the same timing, but different Picture Aspect Ratios 
are considered different formats that can be independently supported and discovered. These are referred 
to as Dual-Aspect Ratio Timings. 

For any Dual-Aspect Ratio Video Timing, the Preferred Picture Aspect Ratio for that timing is indicated by 
the first listing of that timing in the EDID. When receiving a signal not accompanied by an aspect ratio 
indication (because no AVI InfoFrame is transmitted) a DTV shall assume that the aspect ratio is the 
Preferred Picture Aspect Ratio for the transmitted Video Timing. 

If a Dual-Aspect Ratio DTV is receiving a Video Format Timing for which it has declared support for both 
Picture Aspect Ratios in EDID and the Source has indicated the Picture Aspect Ratio by including the AVI 
in the video stream, then the DTV shall display the Picture in the aspect ratio that has been indicated by 
the Source in the AVI. If the Source does not support transmission of the AVI and the Source supports 
both of the Dual-Aspect Ratio Video Timing Formats for a particular Video Timing defined by the Sink, 
then the Source shall provide the video to the DTV in the Preferred Picture Aspect Ratio. 

For a display device to simultaneously support both formats, the Source needs a way to let the display 
device know the Picture Aspect Ratio in which the video should be displayed. A DTV shall list only one 
Picture Aspect Ratio of any Dual-Aspect Ratio Timing unless it is capable of receiving and decoding the 
AVI InfoFrame defined in Section 6. 

However, it is possible for a DTV that has no support for the AVI InfoFrame to still support both aspect 
ratios of such formats as a user programmable option. In that case, the EDID Detailed Timing Descriptor 
could be modified during operation to reflect the selected Picture Aspect Ratio and the change could be 
signaled to the Source (e.g., with Hot Plug Detect on DVI or HDMI). The effects on the EDID data 
structure are explained in Section 7.2.2. See Table 3 for Video ID Code and Aspect Ratios. 


2 2160p Video Formats with 3840 active horizontal pixels 
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VIC 

Formats 

Field Rate 5 

Picture Aspect 
Ratio (HiV) 1 

Pixel Aspect Ratio 
(H:V) 

1 

640x480p 

59.94Hz/60Hz 

4:3 

1:1 

2 

720x480p 

59.94Hz/60Hz 

4:3 

8:9 

3 

720x480p 

59.94Hz/60Hz 

16:9 

32:27 

4 

1280x720p 

59.94Hz/60Hz 

16:9 

1:1 

5 

1920x1080i 

59.94Hz/60Hz 

16:9 

1:1 

6 

720(1440)x480i 

59.94Hz/60Hz 

4:3 

8:9 

7 

720(1440)x480i 

59.94Hz/60Hz 

16:9 

32:27 

8 

720(1440)x240p 

59.94Hz/60Hz 

4:3 

4:9 

9 

720(1440)x240p 

59.94Hz/60Hz 

16:9 

16:27 

10 

2880x480i 

59.94Hz/60Hz 

4:3 

2:9 - 20:9 2 

11 

2880x480i 

59.94Hz/60Hz 

16:9 

8:27 -80:27 2 

12 

2880x240p 

59.94Hz/60Hz 

4:3 

1:9 - 10:9 2 

13 

2880x240p 

59.94Hz/60Hz 

16:9 

4:27 - 40:27 2 

14 

1440x480p 

59.94Hz/60Hz 

4:3 

4:9 or 8:9 3 

15 

1440x480p 

59.94Hz/60Hz 

16:9 

16:27 or 32:27 3 

16 

1920x1080p 

59.94Hz/60Hz 

16:9 

1:1 

17 

720x576p 

50Hz 

4:3 

16:15 

18 

720x576p 

50Hz 

16:9 

64:45 

19 

1280x720p 

50Hz 

16:9 

1:1 

20 

1920x1080i 

50Hz 

16:9 

1:1 

21 

720(1440)x576i 

50Hz 

4:3 

16:15 

22 

720(1440)x576i 

50Hz 

16:9 

64:45 

23 

720(1440)x288p 

50Hz 

4:3 

8:15 

24 

720(1440)x288p 

50Hz 

16:9 

32:45 

25 

2880x576i 

50Hz 

4:3 

2:15 - 20:15 2 

26 

2880x576i 

50Hz 

16:9 

16:45-160:45 2 

27 

2880x288p 

50Hz 

4:3 

1:15 - 10:15 2 

28 

2880x288p 

50Hz 

16:9 

8:45 - 80:45 2 

29 

1440x576p 

50Hz 

4:3 

8:15 or 16:15 3 

30 

1440x576p 

50Hz 

16:9 

32:45 or 64:45 3 

31 

1920x1080p 

50Hz 

16:9 

1:1 

32 

1920x1080p 

23.98Hz/24Hz 

16:9 

1:1 

33 

1920x1080p 

25Hz 

16:9 

1:1 

34 

1920x1080p 

29.97Hz/30Hz 

16:9 

1:1 

35 

2880x480p 

59.94Hz/60Hz 

4:3 

2:9, 4:9, or8:9 4 

36 

2880x480p 

59.94Hz/60Hz 

16:9 

8:27, 16:27, or32:27 4 

37 

2880x576p 

50Hz 

4:3 

4:15, 8:15, or 16:15 4 

38 

2880x576p 

50Hz 

16:9 

16:45, 32:45, or64:45 4 

39 

1920x1080i (1250 total) 

50Hz 

16:9 

1:1 

40 

1920x1080i 

100Hz 

16:9 

1:1 

41 

1280x720p 

100Hz 

16:9 

1:1 

42 

720x576p 

100Hz 

4:3 

16:15 

43 

720x576p 

100Hz 

16:9 

64:45 

44 

720(1440)x576i 

100Hz 

4:3 

16:15 

45 

720(1440)x576i 

100Hz 

16:9 

64:45 


Table 3 Video Formats—Video ID Code and Aspect Ratios 
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VIC 

Formats 

Field Rate 5 

Picture Aspect 
Ratio (HiV ) 1 

Pixel Aspect 

Ratio (H:V) 

46 

1920x1080i 

119.88/120Hz 

16:9 

1:1 

47 

1280x720p 

119.88/120Hz 

16:9 

1:1 

48 

720x480p 

119.88/120Hz 

4:3 

8:9 

49 

720x480p 

119.88/120Hz 

16:9 

32:27 

50 

720(1440)x480i 

119.88/120Hz 

4:3 

8:9 

51 

720(1440)x480i 

119.88/120Hz 

16:9 

32:27 

52 

720x576p 

200Hz 

4:3 

16:15 

53 

720x576p 

200Hz 

16:9 

64:45 

54 

720(1440)x576i 

200Hz 

4:3 

16:15 

55 

720(1440)x576i 

200Hz 

16:9 

64:45 

56 

720x480p 

239.76/240Hz 

4:3 

8:9 

57 

720x480p 

239.76/240Hz 

16:9 

32:27 

58 

720(1440)x480i 

239.76/240Hz 

4:3 

8:9 

59 

720(1440)x480i 

239.76/240Hz 

16:9 

32:27 

60 

1280x720p 

23.98Hz/24Hz 

16:9 

1:1 

61 

1280x720p 

25Hz 

16:9 

1:1 

62 

1280x720p 

29.97Hz/30Hz 

16:9 

1:1 

63 

1920x1080p 

119.88/120Hz 

16:9 

1:1 

64 

1920x1080p 

100Hz 

16:9 

1:1 

65 

1280x720p 

23.98Hz/24Hz 

64:27 6 

4:3 

66 

1280x720p 

25Hz 

64:27 6 

4:3 

67 

1280x720p 

29.97Hz/30Hz 

64:27 6 

4:3 

68 

1280x720p 

50Hz 

64:27 6 

4:3 

69 

1280x720p 

59.94Hz/60Hz 

64:27 6 

4:3 

70 

1280x720p 

100Hz 

64:27 6 

4:3 

71 

1280x720p 

119.88/120Hz 

64:27 6 

4:3 

72 

1920x1080p 

23.98Hz/24Hz 

64:27 6 

4:3 

73 

1920x1080p 

25Hz 

64:27 6 

4:3 

74 

1920x1080p 

29.97Hz/30Hz 

64:27 6 

4:3 

75 

1920x1080p 

50Hz 

64:27 6 

4:3 

76 

1920x1080p 

59.94Hz/60Hz 

64:27 6 

4:3 

77 

1920x1080p 

100Hz 

64:27 6 

4:3 

78 

1920x1080p 

119.88/120Hz 

64:27 6 

4:3 

79 

1680x720p 

23.98Hz/24Hz 

64:27 6 

64:63 

80 

1680x720p 

25Hz 

64:27 6 

64:63 

81 

1680x720p 

29.97Hz/30Hz 

64:27 6 

64:63 

82 

1680x720p 

50Hz 

64:27 6 

64:63 

83 

1680x720p 

59.94Hz/60Hz 

64:27 6 

64:63 

84 

1680x720p 

100Hz 

64:27 6 

64:63 

85 

1680x720p 

119.88/120Hz 

64:27 6 

64:63 

86 

2560x1080p 

23.98Hz/24Hz 

64:27 6 

1:1 

87 

2560x1080p 

25Hz 

64:27 6 

1:1 

88 

2560x1080p 

29.97Hz/30Hz 

64:27 6 

1:1 

89 

2560x1080p 

50Hz 

64:27 6 

1:1 


Table 3 Video Formats—Video ID Code and Aspect Ratios (Continued) 
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128-192 


Table 3 Video 
Formats— 


Formats 


2560x1080p 
2560x1080p 
2560x1080p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
4096x2160p 
4096x2160p 
4096x2160p 
4096x2160p 
4096x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
1280x720p 
1280x720p 
1680x720p 
1920x1080p 
1920x1080p 
2560x1080p 
3840x2160p 
4096x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
3840x2160p 
5120x2160p 
5120x2160p 
5120x2160p 
5120x2160p 
5120x2160p 
5120x2160p 
5120x2160p 
Forbidden 
5120x2160p 
7680x4320p 
7680x4320p 
7680x4320p 


Formats 


Field Rate 5 


59.94Hz/60Hz 

100Hz _ 

119.88/120Hz 

23.98Hz/24Hz 


29.97Hz/30Hz 


59.94Hz/60Hz 

23.98Hz/24Hz 


29.97Hz/30Hz 


59.94Hz/60Hz 

23.98Hz/24Hz 


29.97Hz/30Hz 


59.94Hz/60Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

47.95Hz/48Hz 

100Hz _ 

119.88/120Hz 

100Hz _ 

119.88/120Hz 

23.98Hz/24Hz 


29.97Hz/30Hz 

47.95Hz/48Hz 


59.94Hz/60Hz 

100Hz 


119.88/120Hz 

23.98Hz/24Hz 


29.97Hz/30Hz 


Field Rate 5 


Picture Aspect 
Ratio (HiV ) 1 


64:27 s _ 

64:27 s _ 

64:27 s 


Pixel Aspect 
Ratio (H:V) 


1:1 


256:135 

256:135 

256:135 

256:135 

256:135 

64:27 s 

64:27 s 

64:27 s 

64:27 s 

64:27 s 


64:27 s 


256:135 

64:27 s 


64:27 s 

64:27 s 

64:27 s 

64:27 s 

64:27 s 

64:27 s 

64:27 s 

64:27 s 


Picture Aspect 
Ratio (HiV ) 1 


Pixel Aspect 
Ratio (H:V) 
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Video ID Code 
and Aspect 
Ratios 

(Continued)VIC 


197 _ 7680x4320p _ 47.95Hz/48Hz _ 16:9 _ \j\A _ 

198 _ 7680x4320p _ 50Hz _16T)_ 1A _ 

199 7680x4320p 59.94Hz/60Hz 16:9 1:1 

200 _ 7680x4320p _ 100Hz _m9_ VA _ 

201 _ 7680x4320p _ 119.88/120Hz _m9_ 1_A _ 

202 _ 7680x4320p _ 23.98Hz/24Hz _ 64:27 s _4(3_ 

203 _ 7680x4320p _ 25Hz _ 64:27 s _4(3_ 

204 _ 7680x4320p _ 29.97Hz/30Hz _ 64:27 s _4(3_ 

205 _ 7680x4320p _ 47.95Hz/48Hz _ 64:27 s _4(3_ 

206 _ 7680x4320p _ 50Hz _ 64:27 s _4(3_ 

207 _ 7680x4320p _ 59.94Hz/60Hz _ 64:27 s _4(3_ 

208 _ 7680x4320p _ 100Hz _ 64:27 s _4(3_ 

209 _ 7680x4320p _ 119.88/120Hz _ 64:27 s _4(3_ 

210 _ 10240x4320p _ 23.98Hz/24Hz _ 64:27 s _ VA _ 

211 10240x4320p 25Hz 64:27 s 1:1 

212 _ 10240x4320p _ 29.97Hz/30Hz _ 64:27 s _ VA _ 

213 _ 10240x4320p _ 47.95Hz/48Hz _ 64:27 s _ VA _ 

214 _ 10240x4320p _ 50Hz _ 64:27 s _ VA _ 

215 _ 10240x4320p _ 59.94Hz/60Hz _ 64:27 s _ VA _ 

216 _ 10240x4320p _ 100Hz _ 64:27 s _ VA _ 

217 _ 10240x4320p _ 119.88/120Hz _ 64:27 s _ VA _ 

218 _ 4096x2160p _ 100Hz _ 256:135 _ VI _ 

219 _ 4096x2160p _ 119.88/120Hz _ 256:135 _ VA _ 

220-255 Reserved for the Future 

No Video Identification 

0 Code Available (Used with 

AVI InfoFrame only) 

1. Picture Aspect Ratio—For example, with the 720x480 (16:9) data format and a 4:3 display, the Source could (1) 
use pan and scan information to crop the data to 540 horizontal pixels and then resample up to the required 720 
pixels for output to the display or (2) vertically resample to 360 lines and create Bars of 60 lines above and below it 
to send this “letterbox” with the required 480 lines for output. Other Picture scaling methods are possible in either 
Source or Sink. For example, Picture Aspect Ratio scaling (Picture expand, shrink, etc.) can be accomplished in the 
Source, including, possibly, added black/gray lines in the pixel portion of the video. The exception to this is the 
640x480 format, which is always sent as 4x3 data, and is rendered according to the characteristics of the Sink. 

2. The pixel repeat value can vary from 9 to 0 (see the PR field in Section 6.4) resulting in 10 variations of Pixel 
Aspect Ratio. 

3. The pixel repeat value can be set to 0 or 1 (see the PR field in Section 6.4) resulting in 2 variations of Pixel 
Aspect Ratio. 

4. The pixel repeat value can be set to 0, 1 or 3 (see the PR field in Section 6.4) resulting in 3 variations of Pixel 
Aspect Ratio. 

5. In the case of interlaced formats, the frame rate is 1/2 the field rate. 

6. This Picture Aspect Ratio continues the progression (4:3) A N, where N=1,2, & 3, and is near other wide cinematic 
values in use such as 2.2:1 (SMPTE RP 91 [95]), 21:9, and 2.39:1 (SMPTE RP 40 [94]). 



47.95Hz/48Hz 

16:9 

1:1 

50Hz 

16:9 

1:1 

59.94Hz/60Hz 

16:9 

1:1 

100Hz 

16:9 

1:1 

119.88/120Hz 

16:9 

1:1 

23.98Hz/24Hz 

64:27 s 

4:3 

25Hz 

64:27 s 

4:3 

29.97Hz/30Hz 

64:27 s 

4:3 

47.95Hz/48Hz 

64:27 s 

4:3 

50Hz 

64:27 s 

4:3 

59.94Hz/60Hz 

64:27 s 

4:3 

100Hz 

64:27 s 

4:3 

119.88/120Hz 

64:27 s 

4:3 

23.98Hz/24Hz 

64:27 s 

1:1 

25Hz 

64:27 s 

1:1 

29.97Hz/30Hz 

64:27 s 

1:1 

47.95Hz/48Hz 

64:27 s 

1:1 

50Hz 

64:27 s 

1:1 

59.94Hz/60Hz 

64:27 s 

1:1 

100Hz 

64:27 s 

1:1 

119.88/120Hz 

64:27 s 

1:1 

100Hz 

256:135 

1:1 

119.88/120Hz 

256:135 

1:1 
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Table 3 Video Formats—Video ID Code and Aspect Ratios (Continued) 
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4.2 Frame Rate Relationships 

Some Video Formats have a high frame rate that is an integer (2X, 4X, or 5X) multiple of the frame rate of 
a base (IX) Video Format. While receiving certain low frame rate Video Formats, some Sources may 
calculate extra interpolated frames, and output a related high frame rate Video Format - in order to 
optimize display performance. Table 4 lists the VICs of base Video Formats along with the VICs of their 
higher frame rate counterparts. _ 


Base (IX) 

2X 

4X 

5X 

2 

48 

56 


3 

49 

57 


4 

47 



5 

46 



6 

50 

58 


7 

51 

59 


17 

42 

52 


18 

43 

53 


19 

41 



20 

40 



21 

44 

54 


22 

45 

55 


32 



63 

33 

31 

64 


34 

16 



60 



47 

61 

19 

41 


62 

4 

47 


65 



71 

66 

68 

70 


67 

69 

71 


72 



78 

73 

75 

77 


74 

76 

78 


79 



85 

80 

82 

84 


81 

83 

85 


86 



92 

87 

89 

91 


88 

90 

92 


94 

96 

117 


95 

97 

118 


99 

101 

218 


100 

102 

219 


104 

106 



105 

107 




Table 4 Frame Rate Relationships—Base to High Frame Rate VICs 
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5 Color Encoding, Sampling, & Conversion 
5.1 Default Encoding Parameters 

When present, encoding parameters specified in the AVI InfoFrame, or other interface-specific controls 
(e.g., HDMI General Control Packets), shall take precedence over any default parameters defined in this 
sub-section. 

The default Component Depth shall be 8-bits (N=8). Other elements of the default parameter set vary as 
a function of Video Format Timing type (IT or CE) and (in the case of CE Video Format Timings) vertical 
Active Line count (Vactive). 

When transmitting IT Video Format Timings, the default color space shall be RGB using Full Range 
quantization levels. The RGB color space used for the transmission of IT Video Format Timings should be 
the RGB color space the Sink declares in the Basic Display Parameters and Feature Block of its EDID 
(see Sections A.2.6 and A.2.7 for further information). Most Sources default to RGB color space when 
transmitting IT Video Format Timings. 

If a Source determines that a Sink is incapable of receiving AVI InfoFrames or is incapable of receiving 
YCbCr Pixel Data, then it shall, by default, encode the CE Video Format Pixel Data in RGB color space 
using Limited Range levels. If a Sink is incapable of receiving AVI InfoFrames, incapable of receiving 
YCbCr Pixel Data, or does not receive an AVI InfoFrame, then it should, by default, assume CE Video 
Format Pixel Data is encoded in RGB color space using Limited Range levels and IT Video Format Pixel 
Data is encoded in RGB color space using Full Range levels. In all cases described above, the RGB color 
space used should be the RGB color space the Sink declares in the Basic Display Parameters and 
Feature Block of its EDID. 

If a Source determines that a Sink is capable of receiving AVI InfoFrames and is capable of receiving 
YCbCr Pixel Data, then it shall, by default, encode CE Video Format Pixel Data in a color space 
determined by the vertical Active Line count (Vactive) using Limited Range levels. By default, an SD 
Video Format shall be encoded according to SMPTE 170M [1] color space, an HD Video Format shall be 
encoded according to ITU-R BT.709 [7] color space, and a 2160p Video Format shall also be encoded 
according to ITU-R BT.709 [7] color space. 


5.2 Color Component Samples 

Color is communicated using one of two sets of components: RGB and YCbCr 3 . This interface shall be 
capable of supporting RGB (red, green, and blue), with encoding parameters based on the format. The 
interface may optionally support YCbCr. 

5.2.1 RGB-to-YCeCR Conversion Matrices 

A transformation between YCbCr to RGB generally occurs within the DTV after it receives a YCbCr 
encoded Picture. A transformation between YCbCr Color Component Samples and RGB Color 
Component Samples can be accomplished by applying one of four conversion matrices: ITU-R BT.601 
[6], ITU-R BT.709 [7], ITU-R BT.2020 [39] constant luminance, or ITU-R BT.2020 [39] non-constant 
luminance. The specific conversion matrix required depends on the Colorimetry and Extended 
Colorimetry fields in the AVI InfoFrame. The conversion matrix is either specified explicitly (i.e., the 
Colorimetry field is set to ITU-R BT.601 or ITU-R BT.709) or it is denoted in the subscript of the short 


3 RGB signals have the same notation in the digital and analog domains. Typically, YCbCr notation is used for digital 
domains; and YPbPr is used for analog domains. 
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name of the selected YCbCr colorimetry. For example, the ITU-R BT.601 conversion matrix applied to 
sYCCeoi or opYCCeoi Color Component Samples results in RGB Color Component Samples (both 
positive and negative). 

The ITU-R BT.601 [6] Section 3.5 color space matrix is shown below for convenience. 

Y’= 0.299 R' + 0.587 G’ + 0.114 B’ 

Cr’ = ((R’ - Y’) * 0.71327) 

Cb' = ((B’ - Y’) * 0.56433) 

The ITU-R BT.709 [7] color conversion matrix is shown below for convenience. 

Y’= 0.2126 R’ + 0.7152 G’ + 0.0722 B’ 

Cr’ = ((R’ -Y’)/ 1.5748) 

Cb’ = ((B’ - Y’)/ 1.8556) 

The ITU-R BT.2020 [39] constant luminance color conversion matrix is shown below for convenience. 

Y c ’= (0.2627 R + 0.6780 G + 0.0593 B)’ 

Crc’ = ((R’ - Yc’) /1.7184) for -0.8592 < (R’ - Yc’) < 0 
Crc’ = ((R’ - Yc’) / 0.9936) for 0 < (R’ - Yc’) < 0.4968 
Cbc’ = ((B’ - Yc’) /1.9404) for -0.9702 < (B’ - Yc’) < 0 
Cbc’ = ((B’ - Yc’) /1.5816) for 0 < (B’ - Yc’) < 0.7908 

The ITU-R BT.2020 [39] non-constant luminance color conversion matrix is shown below for 
convenience. 

Y’= 0.2627 R’ + 0.6780 G’ + 0.0593 B’ 

Cr’ = ((R’ - Y’)/1.4746) 

Cb’ = ((B’ -Y’)/1.8814) 

Prime values are transformed levels in non-linear color space (see Transfer Characteristic section). 


5.2.2 Sample Lattice 

In order to improve color reproduction, the sample lattice for RGB and YCbCr 4:2:2 Pixel Data should 
conform to the ITU-R BT.709 [7] sampling lattice. The sample lattice for these Pixel Data encodings are 
described below for convenience: 


• R, G, B, and Y components are orthogonal, line- and picture-repetitive. R, G, and B components 
are co-sited with each other. 

• Cb and Cr are orthogonal, line- and picture-repetitive co-sited with each other and with alternate 
Y samples (starting with the first active Y sample in a line). 

The sample lattice for YCbCr 4:4:4 Pixel Data should be the same as the sample lattice for RGB Pixel 
Data. 
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5.3 Transfer Characteristic (e.g., gamma correction) 

The transfer characteristics for sRGB (as specified in IEC 61966-2-1 [33]) encoded images are shown 
below for convenience. 

L’ = 12.92 * L for 0.0 < L < 0.0031308 

L’ = (1.055 * L A (1.0/2.4) ) - 0.055 for 0.0031308 < L < 1.000 

Where: 

• L is the normalized component level in the range of 0.0 to 1.0 inclusive. 

• L’ is the transformed (gamma corrected) component level. 

The transfer characteristics for sYCC (as specified in IEC 61966-2-1/Amendment.1:2003 [34]) encoded 
images are shown below for convenience. 

L’=-1.055 * L A (1.0/2.4) + 0.055 for L < -0.0031308 
L’=12.92 * L for-0.0031308 <= L <= 0.0031308 
L’=1.055 * L A (1.0/2.4) - 0.055 for 0.0031308 < L 

Where: 

• L is the normalized component level. The lower and upper boundaries of this range may be less 
than 0.0 (negative) and greater than 1.0, respectively. 

• L’ is the transformed (gamma corrected) component level. 

The transfer characteristics for ITU-R BT.709 [7] and ITU-R BT.601 [6] 4 encoded images are shown 
below for convenience. 

L’= 4.5 *Lfor0.0<L< 0.018 

L’ = (1.099 * L A (0.45)) - 0.099 for 0.018 < L < 1.000 

Where: 

• L is the normalized component level in the range of 0.0 to 1.0 inclusive. 

• L’ is the transformed (gamma corrected) component level. 

The transfer characteristics of the image shall conform to IEC 61966-2-4 [5] when AVI InfoFrame Data 
Byte 2 indicates extended color gamut is used. The transfer characteristics for IEC 61966-2-4 [5] encoded 
images are shown below for convenience. Dynamic range compression of luminance components 
brighter than white (i.e., where L is greater than 1.0) should be avoided. 

L’ = (-1.099 * (-L) A (0.45)) + 0.099 for L < -0.018 

L’ = 4.5 * L for -0.018 < L < 0.018 

L’ = (1.099 * L A (0.45)) - 0.099 for L > 0.018 

Where: 

• L is the normalized component level in a range defined by data transmitted in an interface specific 
way according to the capabilities of the Sink, which are identified by EDID bits MD[3:0] (see 
Section 7.5.5). The lower and upper boundaries of this range may be less than 0.0 (negative) and 
greater than 1.0, respectively. 

• L’ is the transformed (gamma corrected) component level. 


4 ITU-R BT.601 [6] does not specify an actual transfer function, however, most DTVs are expected to be 
characterized to approximate the ITU-R BT.709 [7] transfer function. 
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The transfer characteristics for opYCCeoi and opRGB (as specified in IEC 61966-2-5 [32]) encoded 
images are shown below for convenience. 

L’ = L A (1.0/2.2) for 0 < L < 1.0 

Where: 

• L is the normalized component level in the range of 0.0 to 1.0 inclusive. 

• L’ is the transformed (gamma corrected) component level. 

The transfer characteristics for ITU-R BT.2020 [39] encoded images are shown below for convenience. 

At Component Depth of 10-bits: 

L’= 4.5 *Lfor0<L <0.018 

L’ = (1.099 * L A (0.45)) - 0.099 for 0.018 < L < 1 

At Component Depth of 12-bits: 

L’ = 4.5 * L for 0 < L < 0.0181 

L’ = (1.0993 * L A (0.45) ) - 0.0993 for 0.0181 < L < 1 

The transfer characteristics for DCI-P3 (as specified in RP431-2 [51] and EG432-1 [52]) encoded images 
are shown below for convenience. 

L’ = L A (1.0/2.6) for 0 < L < 1.0 

Where: 

• L is the normalized component level in the range of 0.0 to 1.0 inclusive. 

• L’ is the transformed (gamma corrected) component level. 


5.4 Color Coding & Quantization 

Component Depth: The coding shall be N-bit, where N=8, 10, 12, or 16 bits/component - except in 
the case of the default 640x480 Video Timing 1, where the value of N shall be 8. 

Rounding: code = Floor (X + 0.5), where X is the result of a floating point calculation. After rounding, 
code shall be limited according to the range given below. 

Range: Limited Range R, G, B, and Y signals shall have (219*2 A (N-8))+1 quantization levels. Limited 
Range Cb and Cr signals shall have (224*2 A (N-8))+1 quantization levels. Full Range R, G, B, Y, CB, and 
CR signals shall have 2 A N quantization levels. 

Levels: Limited Range R, G, B, and Y signals shall have black level corresponding to code 16*2 A (N-8) 
and peak white level corresponding to code 235*2 A (N-8); Limited Range Cb and Cr signals shall have a 
zero level corresponding to digital code 2 A (N-1) and range spanning codes 16*2 A (N-8) to 240*2 A (N-8). 
Full Range R, G, B, and Y signals shall have a black level corresponding to code 0 and peak white level 
corresponding to code (2 A N)-1. Full Range CB and CR signals shall have a zero level corresponding to 
digital code 2 A (N-1) and range spanning codes 0 to (2 A N)-1. 

Overshoot/Undershoot Regions: If the N-bit digital video signal is converted to an analog signal in 
the Sink, it is recommended that for RGB or Y, the black level (i.e., sync level and blanking level) be 
aligned with the video portion of the signal at black and white digital levels 16*2 A (N-8) and 235*2 A (N-8), 
respectively, such that the Limited Range digital signal swing corresponds to the nominal analog video 
swing (e.g., 0 to 700mV per Sections 9.4, 10.5, and 10.6 of SMPTE 274M [2]). This means that zero 
analog level (0.0 IRE Units) should be associated with digital level 16*2 A (N-8). Digital levels in an 
undershoot region 1 to (16*2 A (N-8))-1 and overshoot region (235*2 A (N-8))+1 to (2 A N)-2 are 
recommended to be passed through the digital to analog converter; however, limited range of the analog 
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signal should be aligned with the range 16*2 A (N-8) to 235*2 A (N-8) since it is expected that this range 
contains essential video. For the 640x480p format, it is recommended that the full 0-255 range be 
displayed for this format. 

Forbidden Values: For Limited Range R, G, B, Y, Cb, Cr signals, codes outside the range 2 A (N-8) to 
(255*2 A (N-8))-1 are reserved and shall not be considered video. 


6 Auxiliary Information Carried from Source to Sink 

Various types of auxiliary data can be carried from the Source to the Sink using InfoFrames. This section 
describes the InfoFrames that have been defined so far. 

The actual mechanism for carrying these InfoFrames may vary depending on the digital interface being 
used 5 . 

Sources and Sinks shall not rely on the Revision Number in the CTA Extension of the Sink’s EDID to 
determine whether a Sink can accept InfoFrames. Sinks shall declare InfoFrame capability by including 
an interface related (e.g., HDMI) VSDB in their EDID CTA Extension. Sources shall only assume 
InfoFrame capability, when an appropriate (e.g., HDMI) VSDB is found. 

NOTE—Previous versions of CTA-861 relied on a Revision Number in the included CTA 
Extension to indicate whether the Sink could accept InfoFrames. Due to a significant number of 
DVI (not InfoFrame-capable) Sinks having the Revision Number set to 3, indicating support of 
InfoFrames, and not being capable of doing so, it is necessary to deprecate this requirement. 

DVI does not support the transmission of any InfoFrames, independent of CTA Extension version 
number. Sinks with a VSDB indicating support for reception of InfoFrames shall accept any of the 
InfoFrames defined here. 

The assigned type codes for InfoFrames are shown in Table 5. The first byte of the InfoFrame designates 
the type of InfoFrame while the second byte indicates the version of that particular InfoFrame. All future 
versions of a specific InfoFrame shall be backward compatible with previous versions. They may contain 
additional information, but old and new devices should be able to access and interpret the information 
previously received. 

Extended InfoFrames are distinct from InfoFrames and are described in Section 6.10. 


5 Neither DVI 1.0 [4] nor OpenLDI 0.95 [8] contain a mechanism for transporting InfoFrames. These physical 
interfaces can be used to implement this standard with reduced functionality. HDMI, which is backward compatible 
with DVI 1.0 and contains mechanisms for transferring InfoFrames, digital audio, and YCbCr Pixel Data, is available 
and can be used to implement the full capabilities of CTA-861. 
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Info Frame 

Type Code 

Type of InfoFrame 

0x00 

Reserved 

0x01 

Vendor-Specific (defined in Section 6.1) 

0x02 

Auxiliary Video Information (defined in Section 6.4) 

0x03 

Source Product Description (defined in Section 6.5) 

0x04 

Audio (defined in Section 6.6 of CTA-861) 

0x05 

MPEG Source (defined in Section 6.7 of CTA-861) 

0x06 

NTSC VBI (defined in Section 6.8 of CTA-861) 

0x07 

Dynamic Range and Mastering (defined in Section 6.9 of CTA-861) 

80x08-0x1 F 

Reserved for future use 

0x20-0xFF 

Forbidden 


Table 5 List of InfoFrame Type Codes 


The InfoFrame Length Field is contained in the third byte of each InfoFrame. This length field is the total 
number of bytes in the InfoFrame Payload. It does not include the Type, Version, or Length fields. In the 
case of the Vendor-Specific InfoFrame, the length includes the IEEE Registration ID, also called OUI, as 
well as any additional bytes defined by the vendor to be in the InfoFrame (see Table 6). The IEEE 
Company ID (CID) can be used in place of the OUI. If the InfoFrame Length field is not set correctly, 
Sinks might not be able to parse the InfoFrame correctly. 

The Vendor-Specific InfoFrame is described in Section 6.1 .The contents of the Auxiliary Video 
Information InfoFrame are described in Section 6.4. The contents of the Product Description InfoFrame 
are described in Section 6.5. The contents of the Audio InfoFrame are described in Section 6.6. The 
contents of the MPEG Source InfoFrame are described in Section 6.7. The contents of the NTSC VBI 
InfoFrame are described in Section 6.8. 

6.1 Vendor-Specific InfoFrames 

The content of the Vendor-Specific InfoFrame is defined in Table 6 and Table 8. This InfoFrame can be 
used by product manufacturers or organizations that have an assigned 24-bit IEEE Registration Identifier 
to transport information not defined elsewhere. The Vendor-Specific Payload would be defined by the 
organization to which the 24-bit IEEE number refers. The 24-bit IEEE number is sent the least significant 
byte first. It is recommended that the Vendor-Specific Payload contain a “length field” to facilitate 
extensibility, but this is not required. 

Any organization or vendor that wishes to define a Vendor-Specific InfoFrame shall obtain a registration 
ID (also known as vendor ID, organizationally unique ID or company ID) from the IEEE Registration 
Authority [92], 


Byte# 

Field Name 

Contents 

n 

VSIF Type Code 

0x01 

n+1 

VSIF Version 

0x01 

n+2 

Lv 

InfoFrame Length 

Total number of bytes in InfoFrame Payload 
including IEEE Registration ID 

n+3 

24 bit IEEE Registration 
Identifier 

IEEE OUI third two hex digits 

n+4 

IEEE OUI second two hex digits 

n+5 

IEEE OUI first two hex digits 

n+6 

Vendor-Specific Payload 

Vendor-Specific Payload 


n+Lv-1 


Table 6 Vendor-Specific InfoFrame (Version 1) 
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Byte # 

Field Name 

Contents 

n 

VSIF Type Code 

0x01 

n+1 

VSIF Version (bits 0-6) 

0x02 

VSIF Change Bit (bit 7) 

0 or 1 

n+2 

Lv 

InfoFrame Length 

Total number of bytes in InfoFrame Payload 
including IEEE Registration ID 

n+3 

24 bit IEEE Registration 
Identifier 

IEEE OUI third two hex digits 

n+4 

IEEE OUI second two hex digits 

n+5 

IEEE OUI first two hex digits 

n+6 

Vendor-Specific Payload 

Vendor-Specific Payload 


n+Lv-1 


Table 7 Vendor-Specific InfoFrame (Version 2) 

6.1.1 Multiple VSIF Handling 

The following requirements ensure the highest level of interoperability with legacy devices that may or 
may not support 1 or more VSIFs and devices supporting the use of VSIFs. 

a. Source devices transmitting one or more Vendor-Specific InfoFrames (VSIFs) shall transmit all 
such VSIFs during a single vertical blanking interval (VBI). In the case of interlaced formats, the 
VSIFs shall be transmitted immediately prior to the first of the two fields. It is permissible to also 
send the VSIF data immediately prior to the second of two fields. 

b. When transmitting Vendor-Specific InfoFrames, Source devices shall transmit all of them at least 
once per two Video Fields. 

c. If a Source device transmits Interface VSIF(s) as well as other VSIF(s), it shall transmit the 
Interface VSIF(s) last. 

d. The information carried in one or more VSIFs transmitted in the same VBI shall apply to the Video 
Field/Frame directly following the VBI. 

e. Sink devices should apply the VSIF information from a given VSIF type to the subsequent 
Field/Frames until a change is transmitted or until a VSIF has not been received for two 
sequential Fields. 

f. InfoFrame information transmitted in non-VSIF(s) and the Interface VSIF(s) should supersede 
any contradictory information transmitted by ordinary VSIFs. 

g. If two (or more) VSIFs in the same VBI carry conflicting information and both are being acted 
upon by the Sink, the information contained within the VSIF received last should take 
precedence. 

h. Sink devices shall read the IEEE Registration Identifier of all VSIFs received in order to properly 
identify and process such VSIFs. 

i. Sink devices that support the processing of multiple VSIFs should support at least four (4) VSIFs 
that arrive as frequently as every VBI. 

j. Source devices shall not transmit identical VSIFs during a single VBI. 

• Vendors may choose to define more than one VSIF, however simultaneous use of multiple 
VSIFs with same OUI is discouraged as this wastes scarce resources in the Sink. 

k. Source and Sink devices should handle any changes to the contents of the VSIFs as a group. 

1. When a Source transmits a sole VSIF, it shall be version 1 (see Table 6). 

2. When a set of multiple VSIFs are transmitted and the Sink’s EDID contains an InfoFrame 
Data Block (see Section 7.5.9), the first VSIF shall be version 2 (see Table 7) and the VSIFs 
that follow it shall be version 1 (see Table 6). In this case, the first VSIF shall indicate 
changes in the set of multiple VSIFs via its VSIF Change Bit 6 , which shall toggle from 0-to-1 


6 Some Sinks have a single VSIF buffer and the ability to generate an interrupt in response to VSIF data changes. 
When the Source transmits a sole VSIF, VSIF interrupts can be interpreted as a change in this sole VSIF and VSIF 
processing in the Sink is infrequent (i.e., only occurs when the Source changes the content of the VSIF) and 
reasonable. However, when a single VSIF buffer is required to process multiple VSIFs, interrupts occur much more 
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or from 1 -to-0 each time the balance of the information in the first VSIF, or contents of any 
other VSIF in the set, changes. 

3. When a set of multiple VSIFs are transmitted and the Sink’s EDID does not contain an 
InfoFrame Data Block, then all VSIFs (including the first) in the set of multiple VSIFs shall be 
version 1 (see Table 6). In this case, the first VSIF, in the series of VSIFs, should 7 have its 
contents changed by at least one bit whenever the contents of any other VSIF, in the set of 
multiple VSIFs, changes. 

4. The Source shall transmit the VSIFs in the same order until any of the VSIFs change. 

I. Sink devices that support additional VSIF processing capabilities shall report those capabilities 
using an InfoFrame Data Block. Source devices shall inspect the InfoFrame Data Block and send 
the appropriate VSIF(s) per the Sink device's capabilities and instructions from the associated 
product manufacturer or organization. Repeaters should report their VSIF processing capability 
and only send those VSIF(s) consistent with the reported capabilities of the downstream Sink 
device. 

6.2 Auxiliary Video Information (AVI) InfoFrame 

This section has been removed (see Section 6.4). 

6.3 Format of Version 1 AVI InfoFrame 

This section has been removed. 

6.4 Format of Version 2, 3, & 4 AVI InfoFrames 

The Auxiliary Video Information (AVI) InfoFrame contains information that describes the Pixel Data 
carried in the next Video Field. It also contains information about the composition of the Picture. Also see 
Section 7 for EDID requirements that relate to the processing of AVI InfoFrames in both Source and 
Sinks. 

If the Source supports the transmission of the Auxiliary Video Information (AVI) and if it determines that 
the Sink is capable of receiving that information, it shall send the AVI to the Sink once per Video Field. 
The data from the AVI applies to the next full frame of video data. 

A Sink capable of receiving a Video Format with Video Identification Code greater than 7 or capable of 
receiving Dual-Aspect Ratio Timing shall be able to receive and decode the AVI InfoFrame described in 
this Section. As required in Section 7.1, a Sink declares the capability of receiving Video Formats 
generated at different Picture Aspect Ratios by listing both Video Formats in its EDID data structure. 
Simultaneous support of timings available in two different aspect ratios shall be indicated by listing both 
formats in the EDID data structure at the same time. 

If, for some reason, an indication is received that conflicts with the Video Format being received (e.g., the 
Source indicates 4:3 but sends the 1920x1080i format), then the Sink shall ignore the conflicting 
information in the AVI. 

If a Sink is capable of receiving YCbCr Pixel Data, then, as defined in Section 7.1, it is required to include 
the Version 3 CTA Extension in its EDID with at least one of the YCbCr chroma sampling format bits set. 
When a Sink’s EDID indicates that it is capable of receiving YCbCr Pixel Data the Sink shall be capable 


often (i.e., once for each VSIF received - since each VSIF received is different from the VSIF received before it) and 
no longer correlate with changes to individual VSIF data. Instead, interrupts signal the arrival of the next VSIF in a set 
of VSIFs. Without special measures, Sink VSIF processing might otherwise dominate available processor bandwidth 
as software would be forced to check for changes in a set of VSIFs on a frame-by-frame basis. To prevent this 
interrupt-overload, designs are used which filter only the first VSIF (or actually the first few bytes of the first VSIF), 
and provide an interrupt if something changes in these bytes. It is with this in mind that a toggle bit is added - to make 
it easy for Sink software to check when data, in a set of VSIFs, has changed - since the Source will toggle the toggle 
bit in the first VSIF to trigger the interrupt. For the Source device, which is creating a set of VSIFs, it is relatively easy 
to toggle a bit when there is a change in any of the VSIFs. 

7 Otherwise, some legacy Sink devices may not know to look for (and act upon) changes in other VSIFs. 
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of receiving AVI InfoFrames. If no AVI InfoFrame is sent from the Source, then, as defined in Section 5.1, 
the Sink is required to assume that all CE Video Formats are encoded in RGB color space using Limited 
Range levels with an 8-bit Component Depth. 

The information on “Active Format Aspect Ratio,” Bar widths, overscan/underscan, non-uniform picture 
scaling, and colorimetry is information that can be used by the Sink to improve the picture quality. Use of 
this information by the Sink is optional. If this information is present at the Source and valid 8 , and if the 
Sink is capable of receiving the AVI, the Source shall send the information. 

NOTE—Previous versions of CTA-861 defined a Version 1 AVI InfoFrame. Support for version 1 
is no longer included in CTA-861. The format of the Version 2 AVI InfoFrame is backward 
compatible with Version 1. All of the fields that were contained in the Version 1 AVI InfoFrame are 
also contained in the Version 2 AVI InfoFrame. Their purpose and use remain unchanged. The 
Version 3 AVI InfoFrame is backwards compatible with Version 2, except for cases where bits Y2 
or VIC7 are set to T. A Version 3 AVI InfoFrame is only used when either of the most-significant 
bits Y2 or VIC7 are set to '1'. 

Sources shall not use AVI InfoFrame version 1. 

All fields of the Version 3 AVI InfoFrame are described in Table 8. All fields of the Version 2 AVI 
InfoFrame are the same as the Version 3, except for the Y, VIC, and Version fields. The Y and VIC fields 
of a Version 2 AVI InfoFrame do not include the most-significant bits Y2 and VIC7 shown. The Y2 and 
VIC7 bits are simply set to zero in a Version 2 AVI InfoFrame and might not be decoded by some Sinks. 

A Version 3 AVI InfoFrame shall be used and the Version field set to 0x03 (indicating that the Sink shall 
decode the additional most-significant bits) whenever either of the most-significant bits Y2 or VIC7 are set 
to 'T. If both Y2 and VIC7 are set to 'O', then a Version 2 AVI InfoFrame shall be used and the Version 
field shall be set to 0x02 (indicating that the Sink does not have to decode the additional most-significant 
bits). 


InfoFrame Type Code 

InfoFrame Type = 0x02 

InfoFrame Version Number 

Version = 0x02 or [0x03) 

Length of AVI InfoFrame 

Length of AVI InfoFrame (13) 

Data Byte 1 

[Y21 

Y1 

Y0 

A0 

B1 

B0 

SI 

SO 

Data Byte 2 

Cl 

CO 

Ml 

M0 

R3 

R2 

R1 

R0 

Data Byte 3 

ITC 

EC2 

EC1 

ECO 

Q1 

Q0 

SCI 

SCO 

Data Byte 4 

[VIC7] 

VIC6 

VIC5 

VIC4 

VIC3 

VIC2 

VIC1 

VICO 

Data Byte 5 

YQ1 

YQ0 

CN1 

CN0 

PR3 

PR2 

PR1 

PRO 

Data Byte 6 

ETB07-ETB00 (Line Number of End of Top Bar - lower 8 bits) 

Data Byte 7 

ETB15-ETB08 (Line Number of End of Top Bar - upper 8 bits) 

Data Byte 8 

SBB07-SBB00 (Line Number of Start of Bottom Bar - lower 8 bits) 

Data Byte 9 

SBB15-SBB08 (Line Number of Start of Bottom Bar - upper 8 bits) 

Data Byte 10 

ELB07-ELB00 (Pixel Number of End of Left Bar - lower 8 bits) 

Data Byte 11 

ELB15-ELB08 (Pixel Number of End of Left Bar - upper 8 bits) 

Data Byte 12 

SRB07-SRB00 (Pixel Number of Start of Right Bar - lower 8 bits) 

Data Byte 13 

SRB15-SRB08 (Pixel Number of Start of Right Bar - upper 8 bits) 


Table 8 Auxiliary Video Information (AVI) InfoFrame Format (Versions 2 & 3) 

All fields of the Version 4 AVI InfoFrame are described in Table 9. All fields of the Version 4 AVI 
InfoFrame are the same as Version 3 AVI InfoFrame, except for the InfoFrame Version Number, Length 
of AVI InfoFrame, and additional Data Byte 14. 


8 The data may not be valid if, for example, the stream was converted from an analog signal with no reliable aspect 
ratio or format information. 


54 





CTA-861-G 


InfoFrame Type Code 

InfoFrame Type = 0x02 

InfoFrame Version Number 

Version = 0x04 

Length of AVI InfoFrame 

Length of AVI InfoFrame (14) 

Data Byte 1 

TY21 

Y1 

Y0 

A0 

B1 

B0 

SI 

SO | 

Data Byte 2 

Cl 

CO 

Ml 

M0 

R3 

R2 

R1 

R0 

Data Byte 3 

ITC 

EC2 

EC1 

ECO 

Q1 

Q0 

SCI 

SCO 

Data Byte 4 

[VIC7] 

VIC6 

VIC5 

VIC4 

VIC3 

VIC2 

VIC1 

VICO 1 

Data Byte 5 

YQ1 

YQ0 

CN1 

CN0 

PR3 

PR2 

PR1 

PRO 

Data Byte 6 

ETB07-ETB00 (Line Number of End of Top Bar - lower 8 bits) 

Data Byte 7 

ETB15-ETB08 (Line Number of End of Top Bar - upper 8 bits) 

Data Byte 8 

SBB07-SBB00 (Line Number of Start of Bottom Bar - lower 8 bits) 

Data Byte 9 

SBB15-SBB08 (Line Number of Start of Bottom Bar - upper 8 bits) 

Data Byte 10 

ELB07-ELB00 (Pixel Number of End of Left Bar - lower 8 bits) 

Data Byte 11 

ELB15-ELB08 (Pixel Number of End of Left Bar - upper 8 bits) 

Data Byte 12 

SRB07-SRB00 (Pixel Number of Start of Right Bar - lower 8 bits) 

Data Byte 13 

SRB15-SRB08 (Pixel Number of Start of Right Bar - upper 8 bits) 

Data Byte 14 

ACE3 

ACE2 

ACE1 ACE0 

F143=0 

F142=0 F141=0 

F140=0 | 


Table 9 Auxiliary Video Information (AVI) InfoFrame Format (Version 4) 

The Sink shall interpret the Y, C, EC, and ACE fields of Data Bytes 1,2, 3, and 14 according to Table 13. 
A value of ‘X’ in the table indicates the Sink shall ignore the bit. A value of ‘D’ in the table indicates the 
Sink shall refer to the IDO’s standard. A reserved value in the table means the colorimetry assumed by 
the Sink is indeterminate. Sources shall be prohibited from setting reserved colorimetry. 


Data Byte 1 (Table 10) contains bits that describe overscan/underscan (e.g., computer graphics or video), 
two bits to indicate the Color Component Sample format and chroma sampling, and other bits to indicate 
the presence of active format and/or Bar Data. If the Bar Data and the active format information do not 
agree, then the Bar Data shall take precedence. 


Data Byte 1, bits Y2, Y1, and Y0 set the Color Component Sample format and chroma sampling format of 
the next Picture. The Source shall first determine if the Sink is capable of receiving YCbCr Pixel Data in 
the defined chroma sampling format prior to sending such data. See Sections 7.1 and 7.5 for a 
description of a Sink’s support of YCbCr chroma sampling formats. 


When the Source transmits YCbCr Pixel Data, the luma component samples of a Coded Frame have a 
one-to-one correlation to the luma component samples of a transmitted Picture, provided that the Source 
does not transform the Coded Frame (i.e., up-/down-scale or frame-rate convert) or add Bars to the 
Coded Frame prior to transmission. In this case, the luma component sample of each Coded Pixel in the 
Coded Frame has a one to one correlation with the luma component sample of each Unique Active Pixel 
in the transmitted Picture. 


Data Byte 1, bit AO indicates whether Active Format Data is present in Data Byte 2 bits R3 through R0. A 
Source device shall set A0=1 when any of the AFD bits are set. 

Data Byte 1, bits B1, and BO indicate the presence and type of Bar Data transmitted in Data Bytes 6 
through 13. The contents of Data Bytes 6 through 13 are described later in this Section. The presence of 
both vertical and horizontal Bar Data is not standardized. 
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B1 

BO 

Bar Data 
Present 

0 

0 

Bar Data 
not 

present 

0 

1 

Vert. Bar 
Info 

present 

1 

0 

Horiz. Bar 
Info 

present 

1 

1 

Vert, and 
Horiz. Bar 
Info 

present 


AO 

Active Format 
Information 
Present 

0 

No Active 
Format 
Information 

1 

Active Format 
(R3...R0) 
Information 
present 


SI 

so 

Scan 

Information 

0 

0 

No Data 

0 

1 

Composed for 
an 

overscanned 
display, where 
some Active 
Pixels and 
lines at the 
edges are not 
displayed. 

1 

0 

Composed for 
an 

underscanned 
display, where 
all Active 

Pixels & lines 
are displayed, 
with or without 
a border. 

1 

1 

Reserved 


Y2 

Y1 

Y0 

RGB or 
YCbCr 

0 

0 

0 

RGB 

(default) 

0 

0 

1 

YCbCr 

4:2:2 

0 

1 

0 

YCbCr 

4:4:4 

0 

1 

1 

YCbCr 

4:2:0 

1 

0 

0 

Reserved 

1 

0 

1 

Reserved 

1 

1 

0 

Reserved 

1 

1 

1 

IDO- 

Defined 


Table 10 AVI InfoFrame Data Byte 1 

Data Byte 1, bits SI, and SO contain information that defines the Picture composition of the next Video 
Field. A Source shall set S=1 (S1=0, S0=1) or S=2 (SI=1, S0=0) if it is confident of the accuracy of those 
values. Otherwise, it shall set S=0 (no data). The Source shall follow these rules for setting S even in the 
absence of an indication that the Sink responds to the value of S. 

A Sink should adjust its scan based on the value of S. A Sink would overscan if it received S=1, and 
underscan if it received S=2. If it receives S=0, then it should overscan for a CE Video Format and 
underscan for an IT Video Format. A Sink should indicate its overscan/underscan behavior using a Video 
Capabilities Data Block (see Section 7.5.6). 

Data Byte 2, bits Ml, and MO contain the Picture Aspect Ratio. When AVI VIC and M are indicated (i.e., 
both are non-zero), the AVI M field shall match the Picture Aspect Ratio entry in Table 3 associated with 
the current Video Format VIC. When VIC=0, the AVI M field may be used to signal a Picture Aspect Ratio 
If M=0 (M1=0, M0=0) and VIC=0, a Sink shall assume the Picture is formatted according to the Preferred 
Picture Aspect Ratio. 

Data Byte 2 (Table 11) contains bits that describe colorimetry, Picture Aspect Ratio, and active format 
information. 
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Data Byte 2, Cl, and CO are used in conjunction with Data Byte 3, EC2 through ECO, and Data Byte 14, 
ACE3 through ACEO, to override the default color spaces and explicitly indicate the colorimetry of the 
next Picture. If bits CO and Cl are zero, the colorimetry shall correspond to the default colorimetry defined 
in Section 5.1. A Source shall be prohibited from setting C=1 (C1=0, C0=1) or C=2 (Cl=1, C0=0) when 
Y=0 (Y2=0, Y1=0, Y0=0) in Data Byte 1. When C=3, colorimetry is indicated in bits ECO through EC2. 


R3 

R2 

R1 

RO 

Active Portion 
Aspect Ratio 

1 

0 

0 

0 

Same as Picture 
Aspect Ratio 

1 

0 

0 

1 

4:3 (Center) 

1 

0 

1 

0 

16:9 (Center) 

1 

0 

1 

1 

14:9 (Center) 

other values 

Varies. See Annex 
H. 


Cl 

CO 

Colorimetry 

0 

0 

No Data 

0 

1 

SMPTE 170M 
[1] 

1 

0 

ITU-R BT.709 [7] 

1 

1 

Extended 
Colorimetry 
Information Valid 
(colorimetry 
indicated in bits 
ECO, EC1, and 
EC2. See Table 
13) 


Ml 

MO 

Picture Aspect 
Ratio 

0 

0 

No Data 

0 

1 

4:3 

1 

0 

16:9 

1 

1 

Reserved 


Table 11 AVI InfoFrame Data Byte 2 

Data Byte 2 bits R3 through RO may be used to communicate common “Active Format” aspect ratio 
information from a Source to a display device. Table 12 illustrates the terminology and gives examples of 
common aspect ratio information. It illustrates some of the possibilities given three standard aspect ratios 
(4:3, 16:9, and 64:27) within the Total Image. For the “greater than 16:9” case, an example aspect ratio of 
64:27 was chosen. 

“Active Format” codes shall be transmitted when received with content. Originating devices supplying 
such codes may provide codes in accordance with the Active Format Description 9 (AFD) in SMPTE 2016- 
1 [35] and ETSI TS 101 154 [68]. All active format codes defined in [35] and [68] are reproduced in 
informative Annex H. 


9 Note that the use of the word “active” in the “Active Format Description” differs from how it is used in other places of 
this standard and documents referenced by this standard. The word, “active” usually refers to all Active Pixels. In this 
case of AFD, the word, “active” refers only to the area containing Content Pixels and its format relative to areas 
potentially containing Bar Pixels. 
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Table 12 Common Active Formats 

See CTA-CEB16-A [67] for more information about AFD processing. 
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Data Byte 3 is divided into four fields as shown in Table 13. 


o 

H 

IT content 

0 

No data 

1 

IT content 
(Byte 5 CN 
bits valid) 


CM 

O 

LU 

EC1 

o 

o 

LU 

Extended 

Colorimetry 

0 

0 

0 

xvYCCeoi 

0 

0 

1 

XVYCC 709 

0 

1 

0 

sYCCeoi 

0 

1 

1 

opYCCeoi 

1 

0 

0 

opRGB 

1 

0 

1 

ITU-R BT.2020 
Y'cC'bcC'rc 

1 

1 

0 

ITU-R BT.2020 
R’G’B’ or 
Y'C'bC'r 

1 

1 

1 

Additional 

Colorimetry 

Extension 

Information 

Valid 

(colorimetry 
indicated in bits 
ACEO, ACE1, 
ACE2, and 
ACE3. See 
Table 25) 


T - 

a 

O 

O 

RGB 

Quantization 

Range 

0 

0 

Default 
(depends on 
Video Format) 

0 

1 

Limited Range 

1 

0 

Full Range 

1 

1 

Reserved 


SCI 

SCO 

Non-Uniform 

Picture 

Scaling 

0 

0 

No Known 

non-uniform 

Scaling 

0 

1 

Picture has 
been scaled 
horizontally 

1 

0 

Picture has 
been scaled 
vertically 

1 

1 

Picture has 
been scaled 
horizontally 
and vertically 


Table 13 AVI InfoFrame Data Byte 3 

Bits SCI and SCO provide information on whether the Picture has been scaled in a non-uniform way (i.e., 
unequal along horizontal and vertical dimensions) prior to transmission to the Sink. The Non-uniform 
Picture Scaling bits shall be set if the Source scales the Picture or has determined that scaling has been 
performed in a specific direction. If the Picture has been stretched or shrunk in a uniform way (i.e., equally 
along both dimensions), then the bits should not be set. 

Displays conforming to CTA-861 accept both limited and Full Range Quantization Range Pixel Data when 
receiving Pictures encoded in an RGB color space. The quantization bits in Data Byte 3, bits Q1 and QO 
allow the Source to override the default RGB Quantization Range and to explicitly indicate the RGB 
Quantization Range of the next Picture. The value Q=0 (Q1=0, Q0=0) indicates that the Quantization 
Range corresponds to the default RGB Quantization Range defined in Section 5.1. A Source shall not 
send a non-zero Q value that does not correspond to the default RGB Quantization Range for the 
transmitted Picture unless the Sink indicates support for the Q bit in a Video Capabilities Data Block (see 
Section 7.5.6). 

The extended colorimetry bits, EC2, EC1, and ECO, describe optional colorimetry encoding that may be 
applicable to some implementations. EC2 through ECO are used in conjunction with Data Byte 2, Cl and 
CO, and Data Byte 14, ACE3 through ACEO, to override the default color spaces and explicitly indicate 
the colorimetry of the next Picture. 
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RGB or 
YCbCr 
( from Data 
Byte 1) 

Colorimetry 
(from Data 
Byte 2) 

Extended 
Colorimetry 
(from Data Byte 3) 

Additional Colorimetry 
Extension 
(from Data Byte 14) 

Colorimetry of 
Next Transmitted 
Picture 

Notes 

171 

171 

17il 

Cl 

CO 

EC2 

EC1 

ECO 

ACE3 

ACE2 

ACE1 


RGB 

4:4:4 

0 

0 

0 

0 

0 

X 

X 

X 

X 

X 

X 

X 

RGB 

1 

0 

0 

0 

0 

1 

X 

X 

X 

X 

X 

X 

X 

Reserved 


0 

0 

0 

1 

0 

X 

X 

X 

X 

X 

X 

X 

Reserved 


0 

0 

0 

1 

1 

0 

X 

X 

X 

X 

X 

X 

Reserved 


0 

0 

0 

1 

1 

1 

0 

0 

X 

X 

X 

X 

opRGB 

2 i 

0 

0 

0 

1 

1 

1 

0 

1 

X 

X 

X 

X 

Reserved 




0 

1 

1 

1 

1 

0 

X 

X 

X 

X 

ITU-R BT.2020 
R'G’B’ [39] 

2,5 



0 

1 

1 

1 

1 

1 

0 

0 

0 

0 

DCI-P3 R’G’B’ 
(D65) 




0 

1 

1 

1 

1 

1 

0 

0 

0 

1 

DCI-P3 R’G’B’ 
(theater) 


0 

0 

0 

1 

1 

1 

1 

1 

0 

X 

1 

X 

Reserved 


0 

0 

0 

1 

1 

1 

1 

1 

1 

X 

X 

X 

Reserved 



Table 14 Picture Colorimetry Indicated by the RGB or YCbCr (Y), Colorimetry (C), Extended 
Colorimetry (EC) and Additional Colorimetry Extension (ACE) Field Settings 
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RGB or 
YCbCr 
( from Data 
Byte 1) 

Colorimetry 
(from Data 
Byte 2) 

Extended 
Colorimetry 
(from Data 
Byte 3) 

Additional Colorimetry 
Extension 
(from Data Byte 14) 

Colorimetry of Next 
Transmitted Picture 

Notes 

171 

171 

171 

El 

CO 

S3 

S3] 

S3] 


ACE2 

ACE1 

ACEO 

YCbCr 

4:2:2 



1 

0 

0 

X 

X 

X 

X 

X 

X 

X 

SMPTE 170M [1] or 
ITU-R BT.709 [7] 

3,4 

0 

0 

1 

0 

1 

D 

B 

B 

X 

X 

X 

X 

SMPTE 170M [1] 

4 

0 

0 

1 

1 

0 

D 

B 

B 

X 

X 

X 

X 

ITU-R BT.709 [7] 

4 

0 

0 

1 

1 

1 

0 

0 

0 

X 

X 

X 

X 

xvYCCeoi 

2,4 

0 

0 

1 

1 

1 

0 

0 

1 

X 

X 

X 

X 

XVYCC 709 

2,4 

0 

0 

1 

1 

1 

0 

1 

0 

X 

X 

X 

X 

sYCCeoi 

2,4 

0 

0 

1 

1 

1 

0 

1 

1 

X 

X 

X 

X 

opYCCeoi 

2,4 

0 

0 

1 

1 

1 

1 

0 

0 

X 

X 

X 

X 

Reserved 




1 

1 

1 

1 

0 

1 

X 

X 

X 

X 

ITU-R BT.2020 
Y'cC'bcC'rc [391 

2,5 



1 

1 

1 

1 

1 

0 

X 

X 

X 

X 

ITU-R BT.2020 

Y'C'bC'r [391 

2,5 

0 

0 

1 

1 

1 

1 

1 

1 

X 

X 

X 

X 

Reserved 


YCbCr 

4:4:4 



0 

0 

0 

X 

X 

X 

X 

X 

X 

X 

SMPTE 170M [1] or 
ITU-R BT.709 [7] 

3,4 

0 

1 

0 

0 

1 

D 

B 

B 

X 

X 

X 

X 

SMPTE 170M [1] 

4 

0 

1 

0 

1 

0 

D 

B 

B 

X 

X 

X 

X 

ITU-R BT.709 [7] 

4 

0 

1 

0 

1 

1 

0 

0 

0 

X 

X 

X 

X 

xvYCCeoi 

2,4 

0 

1 

0 

1 

1 

0 

0 

1 

X 

X 

X 

X 

XVYCC 709 

2,4 

0 

1 

0 

1 

1 

0 

1 

0 

X 

X 

X 

X 

sYCCeoi 

2,4 

0 

1 

0 

1 

1 

0 

1 

1 

X 

X 

X 

X 

opYCCeoi 

2,4 

0 

1 

0 

1 

1 

1 

0 

0 

X 

X 

X 

X 

Reserved 




0 

1 

1 

1 

0 

1 

X 

X 

X 

X 

ITU-R BT.2020 

Y'cC'bcC'rc [391 

2,5,6 



0 

1 

1 

1 

1 

0 

X 

X 

X 

X 

ITU-R BT.2020 
Y'C'bC'r [39] 

2,5 

0 

1 

0 

1 

1 

1 

1 

1 

X 

X 

X 

X 

Reserved 


YCbCr 

4:2:0 

0 

1 

1 

0 

0 

X 

X 

X 

X 

X 

X 

X 

SMPTE 170M [1] or 
ITU-R BT.709 [7] 

3,4 

0 

1 

1 

0 

1 

X 

X 

X 

X 

X 

X 

X 

SMPTE 170M [1] 

4 

0 

1 

1 

1 

0 

X 

X 

X 

X 

X 

X 

X 

ITU-R BT.709 [7] 

4 

0 

1 

1 

1 

1 

0 

0 

0 

X 

X 

X 

X 

xvYCCeoi 

2,4 

0 

1 

1 

1 

1 

0 

0 

1 

X 

X 

X 

X 

XVYCC 709 

2,4 1 

0 

1 

1 

1 

1 

0 

1 

0 

X 

X 

X 

X 

sYCCeoi 

2,4 

0 

1 

1 

1 

1 

0 

1 

1 

X 

X 

X 

X 

opYCCeoi 

2,4 

0 

1 

1 

1 

1 

1 

0 

0 

X 

X 

X 

X 

Reserved 


0 

1 

1 

1 

1 

1 

0 

1 

X 

X 

X 

X 

ITU-R BT.2020 
Y'cC'bcC'rc [391 

2,5 

0 

1 

1 

1 

1 

1 

1 

0 

X 

X 

X 

X 

ITU-R BT.2020 
Y'C'bC'r [39] 

2,5 

0 

1 

1 

1 

1 

1 

1 

1 

X 

X 

X 

X 

Reserved 



Table 14 Picture Colorimetry Indicated by the RGB or YCbCr (Y), Colorimetry (C) and Extended 

Colorimetry (EC) Field Settings (continued) 
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RGB or 
YCbCr 
( from Data 
Byte 1) 

Colorimetry 
(from Data 
Byte 2) 

Extended 
Colorimetry 
(from Data Byte 
3) 

Additional Colorimetry 
Extension 
(from Data Byte 14) 

Colorimetry of 
Next 

Transmitted 

Picture 

Notes 

Y2 

Y1 

Y° 

Cl 

CO 

EC2 

EC1 

ECO 

ACE3 

ACE2 

ACE1 

ACEO 

Reserved 

1 

0 

B 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Reserved 


Reserved 

1 

1 

0 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Reserved 


IDO-Defined 

1 

1 

1 

D 

D 

D 

D 

D 

D 

D 

D 

D 

Defined by IDO 



Notes: 


1. A DTV declares it is capable of displaying Pictures encoded in sRGB colorspace (as defined in IEC 61996-2-1 [33]) 
by setting bit 2 in the Feature Support byte (0x18) of the Basic Display Parameters and Feature Block in its EDID. A 
Sink that declares it is not capable of displaying Pictures encoded in RGB color space declares its colorimetry via the 
values set in bytes 0x19 through 0x22 of the Basic Display Parameters and Feature Block in its EDID. See Sections 
A.2.6 and A.2.7 for further information. 

2. A DTV declares it is capable of displaying Pictures encoded in this colorimetry by setting the associated bit in Byte 3 
of the Colorimetry Data Block in its EDID. See Section 7.5.5 for further information. 

3. The Picture colorimetry is dependent on the value of Vactive for the Video Identification Code set in the AVI 
InfoFrame. See Section 5 for further information. 

4. A DTV declares it is capable of displaying Pictures encoded in this colorimetry by setting bit 4 and/or bit 5 in Byte 3 
of the CTA Extension Version 3 block in its EDID. See Section 7.5. 

5. ITU-R BT.2020 [39] colorimetry is only defined for Component Depths of 10 & 12-bits/component and shall not be 
used at 8-bits/component. 

6. In the case of 4:4:4 sampling, applying the constant luminance (Y'cC'bcC'rc) transform of ITU-R BT.2020 [39] might 

be of little benefit. _ 

Table 14 Picture Colorimetry Indicated by the RGB or YCbCr (Y), Colorimetry (C) and Extended 

Colorimetry (EC) Field Settings (continued) 

The IT content bit in Byte 3 (ITC) indicates when Picture content is directly composed according to 
common IT practices or derived from a specific type of IT content. When the IT content bit of Byte 3 is set 
to 1 (ITC = 1), the content field (CNO, CN1) of Byte 5 is valid and downstream processors should process 
Pixel Data according to the definitions given in Table 15. When the IT content bit of byte 3 is false (ITC = 
0), the content field (CNO, CN1) of Byte 5 should be ignored. The IT content bit is about the Picture 
content and should not be confused with IT vs CE video timings. The IT content bit can be used with both 
video timings. 

Table 15 illustrates the meaning of Data Byte 5 Content Type bits CN1 and CNO. These bits should be 
used to signal delivery of IT content that is either classified as Graphics, Photo, Cinema, or Game. 


CN1 

CNO 

IT Content Type 

0 

0 

Graphics 

o 

1 

Photo 

1 

0 

Cinema 

1 

1 

Game 


Table 15 AVI Info Frame IT Contents Type, Data Byte 5 


The Graphics type is indicated by the Source to flag content composed according to common IT practice 
(i.e., without regard to Nyquist criterion) and is unsuitable for analog reconstruction or filtering. In IT 
applications (e.g., involving bit mapped text), each pixel in the Source’s frame buffer is most clearly 
displayed if it is directly mapped to a light-emitting pixel on the display device - such that adjacent pixels 
are completely independent and do not interact. When the IT content bit is set to 1 and the Graphics type 
is indicated, downstream processors should pass Pixel Data unfiltered and without analog reconstruction. 
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The Photo type is indicated by the Source (which might be a digital still camera, DVD player or other 
device) to flag content derived from digital still pictures. When the Photo type (ITC=1, CN1=0, CN0=1) is 
indicated along with extended colorimetry (Cl = 1, C0=1), the extended colorimetry field (EC2, EC1, ECO) 
of byte 3 shall indicate the color space for Photo content, which may be either sYCCeoi, opYCCeoi, or 
opRGB. When the IT content bit is set to 1 and the Photo type is indicated, the Sink is expected to “pass¬ 
through” still pictures with minimal scaling and picture enhancement in order to avoid undesirable artifacts 
The Photo type should not be associated with device type. For example, digital still cameras may support 
delivery of video. 

The Cinema type is indicated by the Source to flag content derived from cinema material. Audio may be 
processed through an audio video amplifier (AV Amp) or Digital Television. When the IT content bit is set 
to 1 and the Cinema type is indicated, the Sink should “pass-through” cinema content with minimal 
scaling and picture enhancement in order to avoid undesirable artifacts. The Cinema type should not be 
associated with device type. For example, DVD players are capable of supplying various content types 
such as TV programs. 

The Game type is indicated by the Source to flag content derived from game machine material. When the 
IT content bit is set to 1 and the Game type is indicated, the Sink should “pass-through” game content 
with minimal scaling and picture enhancement in order to avoid undesirable artifacts. Audio and video 
latency should also be minimized. The Game type should not be associated with device type. For 
example, game machines are capable of supplying various content types such as DVD movies. 

Displays conforming to CTA-861 may accept both limited and Full Range Quantization Range Pixel Data 
when receiving Pictures encoded in an YCC color space. The YCC Quantization Range bits YQ1 and 
YQO in Data Byte 5, allow the Source to override the normal YCC Quantization Range and to explicitly 
indicate the YCC Quantization Range of the next Picture. Table 16 illustrates the meaning assigned to 
these YCC Quantization Range bits YQ1 and YQO in Data Byte 5. The YQ-field only applies when 
transmitting any YCC colorimetry. A Source shall not send a YQ value that does not correspond to the 
normal YCC Quantization Range specified for the colorimetry transmitted unless the Sink indicates 
support for the YQ bit in a Video Capabilities Data Block (see Section 7.5.6). When transmitting any RGB 
colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted 
(e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore 
the YQ-field. 


YQ1 

YQO 

YCC Quantization Range 

0 

0 

Limited Range 

0 

1 

Full Range 

1 

0 

Reserved 

1 

1 

Reserved 


Table 16 AVI Info Frame YCC Quantization Range, Data Byte 5 


Bits 0 through 7 of byte 4 contain a Video Identification Code (VIC). In most cases, the Video Format can 
be uniquely determined from the Video Format Timing itself. However, if the Source is sending one of the 
Video Formats defined in CTA-861, then it shall set this field to the proper code. If a Video Format not 
listed in CTA-861 is sent, then the Video Identification Code shall be set to 0. If a modified 10 version of a 
Video Format listed in CTA-861 is sent (e.g., modified for some 3D modes or YCbCr 4:2:0), then the 
Video Identification Code shall be set in accordance with the IDO's specification. If this field is used and if 


10 Video timing might be modified from that given in Table 1 and Table 2, when Y=3 (Y2=0, Y1=1, Y0=1) in Data Byte 
1 (i.e., YCbCr 4:2:0), or when Y=7 (Y2=1, Y1 =1, Y0=1) in Data Byte 1 (i.e., IDO-defined), or when an overriding IDO- 
defined 3D mode is present (see Annex O). In the case of YCbCr 4:2:0, the pixel rate is reduced by half, along with 
the Htotal, Hactive, Hblank, Hfront, Hsync, and Hback timing parameters. In the case of 3D, the pixel frequency might 
be doubled and Vsync pulses skipped. 
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it is inconsistent with the Video Format being received, then it shall be ignored by the Sink. If the Picture 
Aspect Ratio implied by this field does not agree with the Picture Aspect Ratio communicated in Data 
Byte 2, then the Picture Aspect Ratio communicated in Data Byte 2 shall be ignored. The codes 
associated with each Video Format are shown in Table 3. These same codes are used in the Short Video 
Descriptors used in the Version 3 CTA Extension, which is described in Section 7.5. 

The following pseudo code illustrates how Sink devices shall interpret VIC codes sent by a Source: 

If VIC = 0 then 

Video Format not documented in CTA-861 (not a “CE Video Format” or “640x480p”). 
Elseif VIC >=1 and VIC <=64 then 

7- bit VIC with bit-7 set to 0 
Elseif VIC >=65 and VIC <=127 then 

8- bit VIC (first set) 

Elseif VIC==128 then 

Reserved 

Elseif VIC >=129 and VIC <=192 then 
Forbidden 

Elseif VIC >=193 and VIC <=253 then 
8-bit VIC (second set) 

Elseif VIC ==254 then 
Reserved 

Elseif VIC == 255 then 
Reserved 

End if 

Data Byte 5 contains the pixel repetition field (PR). The first transmitted Active Pixel of an Active Line 
shall be unique. When PR is zero, the second through the last transmitted Active Pixel shall each be 
unique. When PR is greater than zero, Unique Active Pixels are transmitted less often as the Source shall 
repeat each Unique Active Pixel PR-times. Unique Active Pixels are always vertically aligned and 
horizontally spaced at PR+1 Active Pixel (clock) intervals. The values for PR are shown in Table 17. 


PR3 

PR2 

PR1 

PRO 

Pixel Repetition Factor 

0 

0 

0 

0 

No Repetition (i.e., pixel data sent once) 

0 

0 

0 

1 

Pixel Data sent 2 times (i.e., repeated once) 

0 

0 

1 

0 

Pixel Data sent 3 times 

0 

0 

1 

1 

Pixel Data sent 4 times 

0 

1 

0 

0 

Pixel Data sent 5 times 

0 

1 

0 

1 

Pixel Data sent 6 times 

0 

1 

1 

0 

Pixel Data sent 7 times 

0 

1 

1 

1 

Pixel Data sent 8 times 

1 

0 

0 

0 

Pixel Data sent 9 times 

1 

0 

0 

1 

Pixel Data sent 10 times 

I OxOA-OxOF 

Reserved 


Table 17 AVI InfoFrame Pixel Repetition Field, Data Byte 5 


A Source shall correctly set the PR field whenever it sends an AVI InfoFrame to a Sink - no matter what 
Video Timing Format is being transmitted. A list of allowable PR values for each CE Video Format is 
shown in Table 18. Note that this characteristic is independent of Picture Aspect Ratio. When a Source 
outputs a Video Timing Format with non-repeated pixels, PR shall be set to 0. When a Source outputs a 
double-clocked Video Timing Format, PR shall be set to 1. When a Source outputs Video Timing Formats 
10 through 15, 25 through 30, or 35 through 38, it shall send an AVI InfoFrame indicating the specific PR 
being used and the Sink shall properly interpret it - decimating or repeating pixels depending on the 
signal process. 
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Video Timing Formats with Video Identification Codes 10 through 15, 25 through 30, and 35 through 38 
support variable horizontal resolution. These Video Formats maintain a fixed 1440- or 2880-pixel Hactive 
and use pixel repetition to, in effect, provide different horizontal resolutions. 

Video formats with Video Identification Codes 10 through 13 and 25 through 28 keep Hactive fixed at 
2880 pixels and allow PR to be varied over a 9-to-0 range thereby providing effective resolutions of 288, 
320, 360, 411,480, 576, 720, 960, 1440, and 2880 Unique Active Pixels per Video Line, respectively. In 
addition, gaming formats typically utilize optional left and right Bars, which insure that all of the pixels in a 
game are visible on overscanned displays and further reduce the number of Unique Content Pixels to 
256, 284, 320, 366, 427, 512, 640, 853, 1280, and 2560 pixels, respectively. When Hactive is not an 
integer multiple of PR+1, the Source shall adjust the Bars on each side so that the width of the left Bar is 
an integer multiple of PR+1 and the right Bar begins with a Unique Active Pixel. Table 19 gives 
recommended Bar placement for each value of PR in the form of AVI Bar Data. 

Video formats with Video Identification Codes 14, 15, 29, and 30 allow PR to be set to 1 or 0 thereby 
providing effective resolutions of 720 or 1440 Unique Active Pixels per Video Line, respectively. 

Video formats with Video Identification Codes 35 through 38 allow PR to be set to 3, 1, or 0 thereby 
providing effective resolutions of 720, 1440, or 2880 Unique Active Pixels per Video Line, respectively. 
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VIC Video Description 


J_ 640x480p @ 59.94/60Hz _ 

2, 3 720x480p @ 59.94/60Hz _ 

4,69 1280x720p @ 59.94/60Hz 

_5_ 1920x1080i @ 59.94/60Hz 

6,7 720(1440)x480i @ 59.94/60Hz 

8,9 720(1440)x240p @ 59.94/60Hz 

10,11 2880x480i @ 59.94/60Hz _ 

12, 13 2880x240p @ 59.94/60Hz 

14, 15 1440x480p @ 59.94/60Hz 

16, 76 1920x1080p @ 59.94/60Hz 

17,18 720x576p @ 50Hz _ 

19,68 1280x720p@ 50Hz _ 

20 _ 1920x1080i @ 50Hz _ 

21,22 720(1440)x576i @ 50Hz _ 

23,24 720(1440)x288p @ 50Hz _ 

25, 26 2880x576i @ 50Hz _ 

27, 28 2880x288p @ 50Hz _ 

29,30 1440x576p @ 50Hz _ 

31,75 1920x1080p @ 50Hz _ 

32, 72 1920x1080p @ 23.98/24Hz 

33,73 1920x1080p (a) 25Hz _ 

34, 74 1920x1080p @ 29.98/30Hz 

35, 36 2880x480p @ 59.94/60Hz 

37, 38 2880x576p @ 50Hz _ 

39 _ 1920x1080i (1250) @ 50Hz 

40 _ 1920x1080i @ 100Hz _ 

41.70 1280x720p@100Hz _ 

42,43 720x576p @ 100Hz _ 

44, 45 720(1440)x576i @ 100Hz _ 

46 _ 1920x1080i @ 119.88/120Hz 

47.71 1280x720p @ 119.88/120Hz 

48, 49 720x480p @ 119.88/120Hz 

50, 51 720(1440)x480i @ 119.88/120Hz 

52, 53 720x576p @ 200Hz _ 

54,55 720(1440)x576i @ 200Hz _ 

56, 57 720x480p @ 239.76/240Hz 

58, 59 720(1440)x480i @ 239.76/240Hz 

60, 65 1280x720p @ 23.98Hz/24Hz 

61,66 1280x720p @ 25Hz _ 

62, 67 1280x720p @ 29.97Hz/30Hz 

63,78 1920x1080p @ 119.88Hz/120Hz 

64,77 1920x1080p @ 100Hz _ 

79 _ 1680x720p @ 23.98Hz/24Hz 

80 _ 1680x720p @25Hz _ 

_81_ 1680x720p @ 29.97Hz/30Hz 

82 _ 1680x720p @ 50Hz _ 

83 _ 1680x720p @ 59.94/60Hz 

84 _ 1680x720p @ 100Hz _ 

85 1680x720p @ 119.88Hz/120Hz 


AVI w/PR 

Valid Pixel Repeat Values £ . " 

r Required 


No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

Pixel Data sent 2 times _ No 

Pixel Data sent 1 to 10 times _ Yes 

Pixel Data sent 1 to 10 times _ Yes 

Pixel Data sent 1 to 2 times _ Yes 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

Pixel Data sent 2 times _ No 

Pixel Data sent 1 to 10 times _ Yes 

Pixel Data sent 1 to 10 times _ Yes 

Pixel Data sent 1 or 2 times _ Yes 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

Pixel Data sent 1,2 or 4 times _ Yes 

Pixel Data sent 1,2 or 4 times _ Yes 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

No Repetition _ No 

Pixel Data sent 2 times _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition _ No 

No Repetition No 
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VIC 

Video Description 

Valid Pixel Repeat Values 

AVI w/PR 
Required 

86 

2560x1080p @ 23.98Hz/24Hz 

No Repetition 

No 

87 

2560x1080p (5) 25Hz 

No Repetition 

No 

88 

2560x1080p @ 29.97Hz/30Hz 

No Repetition 

No 

89 

2560x1080p @ 50Hz 

No Repetition 

No 

90 

2560x1080p @ 59.94/60Hz 

No Repetition 

No 

91 

2560x1080p 100Hz 

No Repetition 

No 

92 

2560x1080p (5) 119.88Hz/120Hz 

No Repetition 

No 

93, 103 

3840x2160p @ 23.98Hz/24Hz 

No Repetition 

No 

94, 104 

3840x2160p @25Hz 

No Repetition 

No 

95, 105 

3840x2160p @ 29.97Hz/30Hz 

No Repetition 

No 

96, 106 

3840x2160p 50Hz 

No Repetition 

No 

97, 107 

3840x2160p 59.94Hz/60Hz 

No Repetition 

No 

98 

4096x2160p @ 23.98Hz/24Hz 

No Repetition 

No 

99 

4096x2160p @25Hz 

No Repetition 

No 

100 

4096x2160p @ 29.97Hz/30Hz 

No Repetition 

No 

101 

4096x2160p 50Hz 

No Repetition 

No 

102 

4096x2160p @ 59.94Hz/60Hz 

No Repetition 

No 

108, 109 

1280x720p @ 47.95Hz/48Hz 

No Repetition 

No 

110 

1680x720p @ 47.95Hz/48Hz 

No Repetition 

No 

111 , 112 

1920x1080p @ 47.95Hz/48Hz 

No Repetition 

No 

113 

2560x1080p @) 47.95Hz/48Hz 

No Repetition 

No 

114,116 

3840x2160p (S) 47.95Hz/48Hz 

No Repetition 

No 

115 

4096x2160p @ 47.95Hz/48Hz 

No Repetition 

No 

117, 119 

3840x2160p @ 100Hz 

No Repetition 

No 

118, 120 

3840x2160p @ 119.88/120Hz 

No Repetition 

No 

121 

5120x2160p 23.98Hz/24Hz 

No Repetition 

No 

122 

5120x2160p @25Hz 

No Repetition 

No 

123 

5120x2160p @ 29.97Hz/30Hz 

No Repetition 

No 

124 

5120x2160p @ 47.95Hz/48Hz 

No Repetition 

No 

125 

5120x2160p @ 50Hz 

No Repetition 

No 

126 

5120x2160p 59.94Hz/60Hz 

No Repetition 

No 

127 

5120x2160p 100Hz 

No Repetition 

No 

193 

5120x2160p @ 119.88/120Hz 

No Repetition 

No 

194, 202 

7680x4320p @ 23.98Hz/24Hz 

No Repetition 

No 

195, 203 

7680x4320p @ 25Hz 

No Repetition 

No 

196, 204 

7680x4320p 29.97Hz/30Hz 

No Repetition 

No 

197, 205 

7680x4320p (S) 47.95Hz/48Hz 

No Repetition 

No 

198, 206 

7680x4320p @ 50Hz 

No Repetition 

No 

199, 207 

7680x4320p @ 59.94Hz/60Hz 

No Repetition 

No 

200 , 208 

7680x4320p @ 100Hz 

No Repetition 

No 

201,209 

7680x4320p 119.88/120Hz 

No Repetition 

No 

210 

10240x4320p @ 23.98Hz/24Hz 

No Repetition 

No 

211 

10240x4320p @ 25Hz 

No Repetition 

No 

212 

10240x4320p @ 29.97Hz/30Hz 

No Repetition 

No 

213 

10240x4320p @ 47.95Hz/48Hz 

No Repetition 

No 

214 

10240x4320p 50Hz 

No Repetition 

No 

215 

10240x4320p @ 59.94Hz/60Hz 

No Repetition 

No 

216 

10240x4320p @ 100Hz 

No Repetition 

No 

217 

10240x4320p@ 119.88/120Hz 

No Repetition 

No 

218 

4096x2160p (S) 100Hz 

No Repetition 

No 

219 

4096x2160p 119.88/120Hz 

No Repetition 

No 


Table 18 Valid Pixel Repeat Values for Each Video Format Timing (continued) 
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Unique Active Pixel 
Spacing (in Video 
Pixels) 

Unique 

Active 

Pixels 

Unique 

Content 

Pixels 

AVI 

PR 

AVI 

B 

AVI 

ELB 

AVI 

SRB 

1 

2880 

2560 

0 

1 

160 

2721 

2 

1440 

1280 

1 

1 

160 

2721 

3 

960 

853 

2 

1 

162 

2722 

4 

720 

640 

3 

1 

160 

2721 

5 

576 

512 

4 

1 

160 

2721 

6 

480 

427 

5 

1 

162 

2725 

7 

411 

366 

6 

1 

161 

2724 

8 

360 

320 

7 

1 

160 

2721 

9 

320 

284 

8 

1 

162 

2719 

10 

288 

256 

9 

1 

160 

2721 


Table 19 Typical Gaming Format AVI InfoFrame Parameters 

Data Bytes 6 through 13 provide Bar Data encoded according to the pixel and line numbering scheme of 
CTA-861 as shown in Table 21, which is not compatible with specifications such as SMPTE 2016-1. 

Line counts used to describe a Coded Frame typically conform to SMPTE 2016-1 [35], Table 2, which is 
informatively reproduced in Table 20. 


Format 

Applicable 

Standard 

Coding 

Range 

Pixels x lines 

Coded 

Pixels 1 

Coded Lines 2 

Field 1 

Field 2 

Frame 

480 Interlaced 

SMPTE 125M [62] 

720 x 480 

0-719 

23 - 262 3 

286 -525 3 

- 

480 Progressive 

SMPTE 293M [60] 

720 x 480 

0-719 

- 

- 

45 - 524 

576 Interlaced 

ITU-R BT.656 [75] 

720 x 576 

0-719 

23-310 

336 - 623 

- 

576 Progressive 

ITU-R BT.1358 [77] 

720 x 576 

0-719 

- 

- 

45 - 620 

720 Progressive 

SMPTE 296M [61] 

1280x720 

0-1279 

- 

- 

26 - 745 

1080 Interlaced 

SMPTE 274M [2] 

1920x 1080 

0-1919 

21 -560 

584-1123 

- 

1080 Progressive 

SMPTE 274M [2] 

1920x 1080 

0-1919 

- 

- 

42-1121 


1. SMPTE specifications number Coded Pixels 0-719, while CTA-861 numbers Hactive pixels 1-720. 

2. SMPTE Coded Line numbering scheme is timing-dependent, while CTA-861 Picture Line numbering scheme is 
not. 

3. CTA-861 and SMPTE 2016-1 480i Vactive centers are different. CTA-861's Vactive (22-261/285-524) follows 
archived SMPTE RP 187-1995 recommended practice, while SMPTE2016-1's Vactive (23-262/286-525) is shifted 
down one line and follows current SMPTE RP 202-2008[97] recommended practice. See SMPTE RP202-2008[97] 
Table 1, Note2 and Section 6.1 for further details. 

Table 20 Video Format Information (Informative) 
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The equivalent pixel and line numbering scheme of CTA-861 is shown in Table 21. 


VIC 

Format 

Coding 

Range 

Pixels x lines 

Picture 

Pixel 

Number 

Picture Line Number 

Field 1 

Field 2 

Frame 

6,7 

480 Interlaced 

720 x480 

1 -720 

Odd 1 -479 

Even 2 - 480 

- 

2,3 

480 Progressive 

720 x480 

1 -720 

- 

- 

1 -480 

21,22 

576 Interlaced 

720 x 576 

1-720 

Odd 1 - 575 

Even 2 - 576 

- 

17,18 

576 Progressive 

720 x 576 

1 -720 

- 

- 

1 -576 

4, 19, 60-62, 
108-109 

720 Progressive 

1280x720 

1 - 1280 

- 

- 

1 -720 

5, 20 

1080 Interlaced 

1920x1080 

1 - 1920 

Odd 1 - 

1079 

Even 2 - 1080 

- 

16, 32-34, HI- 
112 

1080 Progressive 

1920x 1080 

1 - 1920 

- 

- 

1 - 1080 

79-85, 110 

720 Progressive 

1680x720 

1-1680 

- 

- 

1 -720 

86-92, 113 

1080 Progressive 

2560x 1080 

1 - 2560 

- 

- 

1-1080 

93-97,103-107, 
114, 116-120 

2160 Progressive 

3840 x2160 

1 - 3840 

- 

- 

1 -2160 

98-102, 115, 
218-219 

2160 Progressive 

4096x2160 

1 - 4096 

- 

- 

1 -2160 

121-127, 193 

2160 Progressive 

5120x2160 

1 -5120 

- 

- 

1 -2160 

194-201 

4320 Progressive 

7680 x 4320 

1 - 7680 

- 

- 

1 - 4320 

202-217 

4320 Progressive 

10240x4320 

1 - 10240 

- 

- 

1 - 4320 


Table 21 CTA-861 Picture Pixel & Line Numbers 


Note that the pixel and line numbering schemes used to encode AFD Bar Data for program material 
conforming to SMPTE 2016-1 are incompatible with those specified in CTA-861. With respect to pixel 
numbering, SMPTE 2016-1 begins with zero, while CTA-861 begins with one. With respect to line 
numbering, SMPTE 2016-1 and CTA-861 timing-based line numbering schemes have been harmonized. 
However, where SMPTE 2016-1 uses timing-based line-numbering for encoding its AFD Bar Data, CTA- 
861 uses a separate Picture-based line-numbering scheme to encode its InfoFrame AFD Bar Data. 
Timing-based line numbering begins with one and at a prescribed line in the blanking interval 1-Ln lines 
relative to the leading line of Vsync. CTA-861’s Picture-based line-numbering also begins with one, but 
always begins at the leading line of Vactive (i.e., the topmost line of the Picture). 

Sources that receive Bar Data from external media (e.g., media carrying Bar Data in accordance with 
SMPTE 2016-1) and output it to Sink via AVI InfoFrame Bar Data, should convert the Bar Data according 
to CTA-861 standard line number and pixel number conventions (given below) prior to outputting. The 
equation for converting SMPTE 2016-1 Coded Pixel numbers (Psmpte) to equivalent CTA-861 Picture 
Pixel numbers (Pcta) is shown in Table 22. The equations for converting interlaced and progressive 
format SMPTE 2016-1 Coded Line numbers (Lsmpte) to equivalent CTA-861 Picture Line numbers (Lcta) 
are shown in Table 23 and Table 24, respectively. The equations in Table 22, Table 23, and Table 24 
only apply when a Bar is present. CTA-861 utilizes special values (given below) when a Bar is omitted. 
The variables Ln, Vsync, Vback, Vfront, Vactive, in the equations come from Table 1 and Table 2 of CTA- 
861. 


Format 

SMPTE 2016-1 Coded Pixel Number to CTA-861 Picture Pixel Number Conversion Equation 

All formats 

Pcta = Psmpte+1 


Table 22 Bar Data Pixel Number Normalization Equation 
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SMPTE 2016-1 Coded Line Number to CTA-861 Picture Line Number Conversion Equations 

Format 

Field 1 

Field 2 


LsMPTE <=[Ln + (Vtotal/2)] 

LsMPTE > [Ln + (Vtotal/2)] 

480 Interlaced 1 

LcTA = 2*[LsMPTE-Ln-V sync-V back]-1 

LCTA — 2*[l_SMPTE-Ln-Vfront -2*(Vsync+Vback)-(Vactive/2)-1 ] 

Other Interlaced 

LCTA = 2*[LSMPTE-Ln-Vsync-Vback+1]-1 

LCTA = 2*[LsMPTE-Ln-Vfront -2*(Vsync+Vback)-(Vactive/2)] 


1. The 480 interlaced format is a special case, where the line number conversion equations are slightly modified due 
to the fact that SMPTE 2016-1 Vactive is offset relative to CTA-861 Vactive by one line (e.g., the bottom-most line in 
SMPTE 2016-1 Vactive ends on timing line number 525, while in CTA-861, it ends one line earlier on timing line 
number 524). All of the other interlaced Video Timings align perfectly. _ 

Table 23 Interlaced Bar Data Line Number Normalization Equations 


Format 

SMPTE 2016-1 Coded Line Number to CTA-861 Picture Line Number Conversion Equation 

All Progressive 

LcTA = LsMPTE-Ln-V sync-V back+1 


Table 24 Progressive Bar Data Line Number Normalization Equation 


The general procedure for converting a SMPTE 2016-1 Coded Pixel number 

(pixel_number_end_of_left_bar or pixel_number_start_of_right_bar) to an equivalent CTA-861 Picture 

Pixel number (ELB or SRB) and setting the CTA-861 vertical Bar Data bit (BO) is: 

1. Determine if a left vertical Bar is present by inspecting the SMPTE 2016-1 left_bar_flag value. If 
the left vertical Bar is present, then use the equation in Table 22 (i.e., simply add one) to calculate 
ELB. If the left vertical Bar is not present, then use the special value zero for ELB. 

2. Determine if a right vertical Bar is present by inspecting the SMPTE 2016-1 right bar flag value. 

If the right vertical Bar is present, then use the equation in Table 22 (i.e., simply add one) to 
calculate SRB. If the right vertical Bar is not present, then use the special value (Hactive+1) for 
SRB. 

3. If either vertical Bar is present, set B0 bit to one. Otherwise, if neither vertical Bar is present, set 
B0 bit to zero. 

The general procedure for converting a SMPTE 2016-1 Coded Line number 

(line_number_end_of_top_bar or line_number_start_of_bottom_bar) to a CTA-861 Picture Line number 

(ETB or SBB) and setting the CTA-861 horizontal Bar Data bit (B1) is: 

1. Determine if top horizontal Bar is present by inspecting the SMPTE 2016-1 top_bar_flag value. If 
the top horizontal Bar is not present, then use the special value zero for ETB. If the top horizontal 
Bar is present and the Video Format is progressive, then use the equation in Table 24 to 
calculate ETB. Otherwise, use one of the four equations as described in step 3 below to calculate 
ETB. 

2. Determine if bottom horizontal Bar is present by inspecting the SMPTE 2016-1 bottom_bar_flag 
value. If the bottom horizontal Bar is not present, then use the special value (Vactive+1) for SBB. 

If the bottom horizontal Bar is present and the Video Format is progressive, then use the equation 
in Table 24 to calculate SBB. Otherwise, use one of the four equations as described step 3 below 
to calculate SBB. 

3. If a horizontal Bar is present and the Video Format is interlaced, then use one of the four 
equations in Table 23 as follows: 

a. Determine if the SMPTE 2016-1 line number is in the first field by comparing the 
number with the value [Ln + (Vtotal/2)]. If the SMPTE 2016-1 number is less than 
or equal to the value [Ln + (Vtotal/2)], then use one of the equations from the “Field 
1” column of Table 23. Otherwise, use one of the equations from the “Field 2” 
column of Table 23. 

b. If the incoming Video Format is 480i, then use the appropriate equation from the 
“480 Interlaced” row of Table 23. Otherwise, use the appropriate equation from the 
“Other Interlaced” row of Table 23. 
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4. If either horizontal Bar is present, set B1 bit to one. Otherwise, if neither horizontal Bar is present, 
set B1 bit to zero. 

Example Bar Data conversions are shown in Annex M. 

Data Bytes 6 through 13 contain the location data for Bars. These 8 bytes are present in the AVI whether 
or not they contain the Bar Data. For the purposes of the Line Number and the Pixel Number, the pixel in 
the upper left hand corner of the Picture is considered to be in row 1, column 1. Lines and pixels are 
numbered consecutively as they would appear on a display. 11 All of the values are unsigned integers. 

a) Line Number of End of Top Bar (ETB) — An unsigned integer value representing the last line of a 
horizontal letterbox Bar area at the top of the Picture. Zero means no horizontal Bar is present at the 
top of the Picture. 

b) Line Number of Start of Bottom Bar (SBB) — An unsigned integer value representing the first line of 
a horizontal letterbox Bar area at the bottom of the Picture. If greater than the Maximum Vertical Active 
Lines of the known format, no horizontal Bar is present at the bottom of the Picture. 

c) Pixel Number of End of Left Bar (ELB) — An unsigned integer value representing the last horizontal 
pixel of a vertical pillar-Bar area at the left side of the Picture. Zero means no vertical Bar is present on 
the left of the Picture. 

d) Pixel Number of Start of Right Bar (SRB) — An unsigned integer value representing the first 
horizontal pixel of a vertical pillar-Bar area at the right side of the Picture. If greater than the Maximum 
Horizontal Pixels of the known format, no vertical Bar is present on the right side of the Picture. 

Data Byte 14, bits ACE3 through ACEO, are used in conjunction with Data Byte 2, Cl through CO, and 
Data Byte 3, EC2 through ECO, to override the default color spaces and explicitly indicate the colorimetry 
of the next Picture. 


ACE3 

ACE3 

ACE1 

ACEO 

Additional Colorimetry Extension 

0 

0 

0 

0 

DCI-P3 R’G’B’ (D65) 

0 

0 

0 

1 

DCI-P3 R’G’B’ (theater) 

0x02-0x0F 

Reserved 


Table 25 AVI InfoFrame Data Byte 14 Additional Colorimetry Extension (ACE) Bits 


6.5 Source Product Description (SPD) InfoFrame 

The Source Product Description (SPD) InfoFrame communicates the name and product type of the 
Source. This allows the user to see which device is being selected when changing inputs on the Sink. 

Including an appropriate VSDB in the Sink’s EDID data structure indicates support of the SPD InfoFrame 
in the Sink. The transmission of this InfoFrame is optional for the Source. The use of the information by 
the Sink is also optional. It shall not be sent more than once per Video Frame. If used, it is recommended 
that it be sent once every second. 

The format of the Source Product Description InfoFrame is shown in Table 26. 


11 In this context, line numbers are not the same as the line numbers used in timing diagrams. 
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InfoFrame Type Code 

InfoFrame Type = 0x03 

InfoFrame Version Number 

Version = 0x01 

Length of Source Product 
Description InfoFrame 

Length of Source Product Description InfoFrame = 25 

Data Byte 1 

0 

Vendor Name Character 1 VN1 (7bit ASCII code) 

Data Byte 2 

0 

Vendor Name Character 2 VN2 

Data Byte 3 

0 

Vendor Name Character 3 VN3 

Data Byte 4 

0 

Vendor Name Character 4 VN4 

Data Byte 5 

0 

Vendor Name Character 5 VN5 

Data Byte 6 

0 

Vendor Name Character 6 VN6 

Data Byte 7 

0 

Vendor Name Character 7 VN7 

Data Byte 8 

0 

Vendor Name Character 8 VN8 

Data Byte 9 

0 

Product Description Character 1 PD1 (7-bit ASCII code) 

Data Byte 10 

0 

Product Description Character 2 PD2 

Data Byte 11 

0 

Product Description Character 3 PD3 

Data Byte 12 

0 

Product Description Character 4 PD4 

Data Byte 13 

0 

Product Description Character 5 PD5 

Data Byte 14 

0 

Product Description Character 6 PD6 

Data Byte 15 

0 

Product Description Character 7 PD7 

Data Byte 16 

0 

Product Description Character 8 PD8 

Data Byte 17 

0 

Product Description Character 9 PD9 

Data Byte 18 

0 

Product Description Character 10 PD10 

Data Byte 19 

0 

Product Description Character 11 PD11 

Data Byte20 

0 

Product Description Character 12 PD12 

Data Byte 21 

0 

Product Description Character 13 PD13 

Data Byte 22 

0 

Product Description Character 14 PD14 

Data Byte 23 

0 

Product Description Character 15 PD15 

Data Byte 24 

0 

Product Description Character 16 PD16 

Data Byte 25 

Source Information [ 


Table 26 Source Product Description InfoFrame Format 


The Vendor Name consists of eight 7-bit ASCII characters. The name should be left justified (i.e., first 
character in Data Byte 1) and all unused characters should be Null (i.e., 0x00). The Vendor Name is 
intended to be the name of the company whose name appears on the product. The Product Description 
(contained in Data Bytes 9-24) consists of sixteen 7-bit ASCII characters. This code is meant to be the 
model number of the product and may contain a short description also (e.g., CE524DVD Player). Data 
Byte 25 consists of a code that classifies the Source. Codes for the most common types of Sources are 
shown in Table 27. 
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Code 

Source Information 

0x00 

unknown 

0x01 

Digital STB 

0x02 

DVD player 

0x03 

D-VHS 

0x04 

HDD Videorecorder 

0x05 

DVC 

0x06 

DSC 

0x07 

Video CD 

0x08 

Game 

0x09 

PC general 

OxOA 

Blu-Ray Disc (BD) 

0x0 B 

Super Audio CD 

OxOC 

HD DVD 

0x0 D 

PMP 

0x0 E 

Reserved 

OxFF 



Table 27 Source Product Description InfoFrame Data Byte 25 
6.6 Audio InfoFrame 

The Audio InfoFrame contains information that allows for the format of the digital audio streams to be 
identified more quickly via out-of-band information and, for multi-channel Uncompressed Audio (which 
does not otherwise give such information), provides channel allocation information for the Sink’s 
speakers. The Audio InfoFrame format is shown in Table 28. 

If the Sink supports any digital audio, it shall be capable of receiving the Audio InfoFrame and also 
capable of interpreting the audio identification information in Data Bytes 1-3. Support for digital audio 
other than Basic Audio is indicated in the Version 3 (or higher) CTA Extension (see Section 7.5). 

If the Sink supports multi-channel (i.e., more than 2 channels) digital audio and has included speaker 
placement information in EDID (see Section 7.5), it shall be able to interpret the speaker channel 
assignment information and down-mix information in Data Bytes 4 & 5. 

If the Source supports the transmission of the Audio InfoFrame and if it determines that the Sink is 
capable of receiving the Audio InfoFrame (i.e., the Sink has included CTA Extension Version 3 in EDID) 
and digital audio, then the Audio InfoFrame, with Data Bytes 1 through 3 set correctly, shall be sent once 
per Video Field while digital audio is being sent across the interface. The data applies to the audio 
associated with the next full frame of video data. 

If the Source is sending multi-channel Uncompressed Audio, then it shall also send valid speaker channel 
allocation information and down-mix information in Data Bytes 4 & 5 of this InfoFrame. 
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InfoFrame Type 
Code 

InfoFrame Type = 0x04 

InfoFrame 
Version Number 

Version = 0x01 

Length of Audio 
InfoFrame 

Length of Audio InfoFrame = 10 

Data Byte 1 

CT3 

CT2 

CT1 

CTO 

F13=0 

CC2 

CC1 

CCO 

Data Byte 2 

F27=0 

F26=0 

F25=0 

SF2 

SF1 

SF0 

SSI 

SSO 

Data Byte 3 

F37=0 

F36=0 

F35=0 

CXT4 

CXT3 

CXT2 

CXT1 

CXT0 

Data Byte 4 

CA7 

CA6 

CA5 

CA4 

CA3 

CA2 

CA1 

CA0 

Data Byte 5 

DM INH 

LSV3 

LSV2 

LSV1 

LSV0 

F52=0 

LFEPBL1 

LFEPBL0 

Data Byte 6 

F67=0 

F66=0 

F65=0 

F64=0 

F63=0 

F62=0 

F61=0 

F60=0 

Data Byte 7 

F77=0 

F76=0 

F75=0 

F74=0 

F73=0 

F72=0 

F71=0 

F70=0 

Data Byte 8 

F87=0 

F86=0 

F85=0 

F84=0 

F83=0 

F82=0 

F81=0 

F80=0 

Data Byte 9 

F97=0 

F96=0 

F95=0 

F94=0 

F93=0 

F92=0 

F91=0 

F90=0 

Data Byte 10 

FI 07=0 

FI 06=0 

FI 05=0 

FI 04=0 

FI 03=0 

FI 02=0 

F101=0 

FI 00=0 


Table 28 Audio InfoFrame Format When Byte 4 is 0x00 to 0x31 


InfoFrame Type 
Code 

InfoFrame Type = 0x04 

InfoFrame 
Version Number 

Version = 0x01 

Length of Audio 
InfoFrame 

Length of Audio InfoFrame = 10 

Data Byte 1 

CT3 

CT2 

CT1 

CTO 

F13=0 

CC2 

CC1 

CCO 

Data Byte 2 

F27=0 

F26=0 

F25=0 

SF2 

SF1 

SF0 

SSI 

SSO 

Data Byte 3 

F37=0 

F36=0 

F35=0 

CXT4 

CXT3 

CXT2 

CXT1 

CXT0 

Data Byte 4 

1 

1 

1 

1 

1 

1 

1 

0 

Data Byte 5 

DM INH 

LSV3 

LSV2 

LSV1 

LSV0 

F52=0 

LFEPBL1 

LFEPBL0 

Data Byte 6 

FLW / 
FRW 

RLC / 
RRC 

FLC/ 

FRC 

BC 

BL/ 

BR 

FC 

LFE1 

FL/ 

FR 

Data Byte 7 

TpSiL/ 

TpSiR 

SiL/ 

SiR 

TpBC 

LFE2 

LS/RS 

TpFC 

TpC 

TpFL/ 

TpFR 

Data Byte 8 

F87=0 

F86=0 

F85=0 

F84=0 

TpLS / 
TpRS 

BtFL/ 

BtFR 

BtFC 

TpBL/ 

TpBR 

Data Byte 9 

F97=0 

F96=0 

F95=0 

F94=0 

F93=0 

F92=0 

F91=0 

F90=0 

Data Byte 10 

FI 07=0 

FI 06=0 

FI 05=0 

FI 04=0 

FI 03=0 

FI 02=0 

F101=0 

FI 00=0 


Table 29 Audio InfoFrame Format When Byte 4 is OxFE 


InfoFrame Type 
Code 

InfoFrame Type = 0x04 

InfoFrame 
Version Number 

Version = 0x01 

Length of Audio 
InfoFrame 

Length of Audio InfoFrame = 10 

Data Byte 1 

CT3 

CT2 

CT1 

CTO 

F13=0 

CC2 

CC1 

CCO 

Data Byte 2 

F27=0 

F26=0 

F25=0 

SF2 

SF1 

SF0 

SSI 

SSO 

Data Byte 3 

F37=0 

F36=0 

F35=0 

CXT4 

CXT3 

CXT2 

CXT1 

CXT0 

Data Byte 4 

1 

1 

1 

1 

1 

1 

1 

1 

Data Byte 5 

DM INH 

LSV3 

LSV2 

LSV1 

LSV0 

F52=0 

LFEPBL1 

LFEPBL0 

Data Byte 6 

CID07 

CID06 

CID05 

CID04 

CID03 

CID02 

CID01 

CID00 

Data Byte 7 

CID15 

CID14 

CID13 

CID12 

CID11 

CID10 

CID09 

CID08 

Data Byte 8 

CID23 

CID22 

CID21 

CID20 

CID19 

CID18 

CID17 

CID16 

Data Byte 9 

CID31 

CID30 

CID29 

CID28 

CID27 

CID26 

CID25 

CID24 

Data Byte 10 

FI 07=0 

FI 06=0 

FI 05=0 

FI 04=0 

FI 03=0 

FI 02=0 

F101=0 

FI 00=0 


Table 30 Audio InfoFrame Format When Byte 4 is OxFF 
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6.6.1 Audio Identification Information 

The information in Data Bytes 1-3 may be useful in identifying the audio format, audio channel count, 
audio sampling frequency, and number of bits per audio sample. If the DTV and the Source support more 
than “Basic Audio,” as defined by the physical/iink specification, then this information shall be sent and 
shall accurately identify the stream while digital audio is being sent. If the Source only supports Basic 
Audio, it is not required to send this information, but it is recommended. In most cases, it is possible to 
identify the audio by parsing the actual audio stream (e.g., as specified in IEC 60958-3 [12]). In cases 
where the audio information in the Audio InfoFrame does not agree with the actual audio stream being 
received, the conflicting information in the Audio InfoFrame shall be ignored. 

NOTE—HDMI requires the CT, SS, and SF fields to be set to 0 (“Refer to Stream Header”) when 
these items are indicated elsewhere. By extension the CXT field is also required to be set to 0. 

Data Byte 1 bits CT3, CT2, CT 1, and CTO, when coded, define the audio format type of the audio stream. 
These bits may be set according to Table 31. A Sink capable of receiving digital audio shall determine the 
audio format by parsing the audio stream header when CT=0 (CT3=0, CT2=0, CT1=0, CT0=0). Audio 
format types shall be defined by the CXT field in Data Byte 3 when CT=15 (CT3=1, CT2=1, CT1=1, 

CT0=1). 

Data Byte 1, bits CC2, CC1, and CCO, when coded, indicate the audio channel count carried transmitted 
in the audio stream. These bits may be set according to Table 31. When CC=0 (CC2=0, CC1=0, CC0=0), 
channel count may be determined either by examining Data Bytes 4 and 6 to 9 (in the case of L-PCM 
audio or DSD audio) or from information in the bitstream (in the case of compressed audio). In some 
cases (e.g., with Object Based Audio, or compressed streams containing multiple channel layouts) the 
channel count of the rendered audio is determined by the Sink device. _ 


c 

T 

3 

c 

T 

2 

c 

T 

1 

c 

T 

0 

Audio Coding 
Type 

Audio Stream 
Encoding Standard 

Audio Stream 
Transport 
Standard 

0 

0 

0 

0 

Refer to Stream Header 

0 

0 

0 

1 

L-PCM 

IEC 60958-3 [121 II 

0 

0 

1 

0 

AC-3 

ATSC A/52B [11], 
excluding Annex E 

IEC 61937-3 [14] 

0 

0 

1 

1 

MPEG-1 

ISO/IEC 11172-3 [23] 
Layer 1 or Layer 2 

IEC 61937-4 [15] 

0 

1 

0 

0 

MP3 

ISO/IEC 11172-3 [23] 
Layer 3 

IEC 61937-4 [15] 

0 

1 

0 

1 

MPEG2 

ISO/IEC 13818-3 [24] 

IEC 61937-4 [15] 

0 

1 

1 

0 

AAC LC 

ISO/IEC 14496-3 [251 

IEC 61937-6 [171 

0 

1 

1 

1 

DTS 

ETSI TS 102 114 [36] 

IEC 61937-5 [16] 

1 

0 

0 

0 

ATRAC 

IEC 61909 [13], See 
also ATRAC [82] 

IEC 61937-7 [18] 

1 

0 

0 

1 

One Bit Audio 

ISO/IEC 14496-3 [25], subpart 10, See 
also Super Audio CD [91]. 

1 

0 

1 

0 

Enhanced AC-3 

ATSC A/52B [11], with 
Annex E 

IEC 61937-3 [14] 

1 

0 

1 

1 

DTS-HD 

ETSI TS 102 114 [36] 

IEC 61937-5 [16] 

1 

1 

0 

0 

MAT 

DVD Forum MLP [27] 

IEC 61937-9 [20] 

1 

1 

0 

1 

DST 

ISO/IEC 14496-3 [25] subpart 10 1 

1 

1 

1 

0 

WMA Pro 

WMA Pro Decoder 
Specification [29] 

IEC 61937-8 [19] 

1 

1 

1 

1 

Refer to Audio Coding Extension Type (CXT) field in Data 

Byte 3 


C 

m 

c 

Audio 

C 

H 

c 

Channel 

2 

D 

D 

Count 




Refer to 

0 

0 

0 

Stream 

Header 

□ 

O 

~ 

2 channels 

0 

i 

0 

3 channels 

0 

i 

1 

4 channels 

1 

0 

0 

5 channels 

D 

O 

— 

6 channels 

i 

i 

0 

7 channels 

i 

i 

1 

8 channels 


Table 31 Audio InfoFrame Data Byte 1 
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Data Byte 2, bits SF2, SF1, and SFO, when coded, indicate the audio sampling frequency in the audio 
stream. These bits shall be set according to Table 32. A Sink capable of receiving digital audio shall 
determine the audio sampling frequency by parsing the audio stream header when SF=0 (SF2=0, SF1=0, 
SF0=0). 

Data Byte 2, bits SSI and SSO, when coded, indicate the number of bits per audio sample in the audio 
stream. These bits shall be set according to Table 32. A Sink capable of receiving digital audio shall 
determine the number of bits per audio sample by parsing the audio stream header when SS=0 (SSI =0, 
SS0=0) 


SF2 

SF1 

SFO 

Sampling Frequency 

0 

0 

0 

Refer to Stream Header 

0 

0 

1 

32 kHz 

0 

1 

0 

44.1 kHz (CD) 

0 

1 

1 

48 kHz 

1 

0 

0 

88.2 kHz 

1 

0 

1 

96 kHz 

1 

1 

0 

176.4 kHz 

1 

1 

1 

192 kHz 


SSI 

SSO 

Sample Size 

0 

0 

Refer to Stream header 

0 

1 

16 bit 

1 

0 

20 bit 

1 

1 

24 bit 


Table 32 Audio InfoFrame Data Byte 2 

Data Byte 3, bits CXT4, CXT3, CXT2, CXT1, and CXTO, when coded and when the CT field in Data Byte 
1 is set to 15, indicate the audio format type of the audio stream. The CXT4-CXT0 bits shall be set to 
0x00 (CXT4=0, CXT3=0, CXT2=0, CXT1=0, CXT0=0) when the CT field in Data Byte 1 is set to a value 
other than 15. When the CT field in Data Byte 1 is set to 15 (CT3=1, CT2=1, CT1=1, CT0=1) the CXT bits 
may be set according to Table 33. When CXT=0 (CXT4=0, CXT3=0, CXT2=0, CXT1=0, CXT0=0) a Sink 
capable of receiving digital audio shall determine the audio format by analyzing the value of the CT field 
in Data Byte 1 or by parsing the audio stream header. 


CXT 

Audio Coding 
Extension Type 

Audio Stream Encoding Standard 

Audio Stream 
Transport Standard 

0x00 

Refer to Audio Coding Type (CT) field in Data Byte 1 

0x01 

Not in use 

0x02 

Not in use 

0x03 

Not in use 

0x04 

MPEG-4 HE AAC 

ISO/IEC 14496-3 [25] 

IEC 61937-11 [21] 

0x05 

MPEG-4 HE AAC v2 

ISO/IEC 23003-1 [26] 

IEC 61937-11 [21] 

0x06 

MPEG-4 AAC LC 

ISO/IEC 14496-3 [25] 

IEC 61937-11 [211 ! 

0x07 

DRA 

GB/T 22726 [38] 

IEC 61937-12 [22] 

0x08 

MPEG-4 HE AAC + 
MPEG Surround 

ISO/IEC 14496-3 [25], 

ISO/IEC 23003-1 [261 

IEC 61937-11 [21] 

0x09 

Reserved 

OxOA 

MPEG-4 AAC LC + 
MPEG Surround 

ISO/IEC 14496-3 [25], 

ISO/IEC 23003-1 [261 

IEC 61937-11 [21] 

0x0 B 

MPEG-H 3D Audio 

ISO/IEC 23008-3 [43] 

IEC 61937-13 [46] 

OxOC 

AC-4 

ESTI TS 103 190 [45] 

IEC 61937-14 [47] 

0x0 D 

L-PCM 3D Audio 

IEC 60958-3 [48] 


EOxOE-OxlF 

Reserved 


Table 33 Additional Audio Format Code Extension Values (Data Byte 3) 
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6.6.2 Speaker Mapping and Down-mix Information 

Data Bytes 4 and 5 apply only to multi-channel (i.e., more than two channels) Uncompressed Audio. 

Data Byte 4 contains information that describes how various speaker locations are allocated to 
transmission channels. Data Byte 5 contains information that tells the Sink how much the Source 
attenuated the audio during a down-mixing operation. The down-mix inhibit flag (DMJNH) describes 
whether audio output is permitted to be down-mixed or not. This flag is used in DVD Audio applications 
(see Table 37). 

The labels and placements of speakers used in CTA-861 are defined in Figure 6 and Table 34 (see 
Annex K for additional information concerning speaker placement relationships between CTA-861 and 
other standards). 


FLC 


BtFL 



FL 



BtFC 


FC 


FRC 


FR 


BtFR 


FLW 


FpFL 


fpFC 


TpFF 


FR\A 


SiL 


fpSil. 


TpC 


pSiF: 


SiR 



rpBL 


fpBF 


fpBC 


RS 


BL 


BR 


BC 


Figure 6 Speaker Placement 


The Speaker labels and descriptions in Table 34 are consistent with those in ISO/IEC 62574 [42]. Annex 
Q describes how the naming convention in Table 34 relates to prior revisions of CTA-861. 
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Note that the speaker location names are informatively associated to geometrical speaker positions as 
per Rec. ITU-R BS.2051-0 [105], 


Label 

Position Description 

Code 

FL 

Front Left 

0x00 

FR 

Front Right 

0x01 

FC 

Front Center 

0x02 

LFE1 

Low Frequency Effects 1 

0x03 

BL 

Back Left 

0x04 

BR 

Back Right 

0x05 

FLc 

Front Left of Center 

0x06 

FRc 

Front Right of Center 

0x07 

BC 

Back Center 

0x08 

LFE2 

Low Frequency Effects 2 

0x09 

SiL 

Side Left 

OxOA 

SiR 

Side Right 

0x0 B 

TpFL 

Top Front Left 

OxOC 

TpFR 

Top Front Right 

0x0 D 

TpFC 

Top Front Center 

0x0 E 

TpC 

Top Center 

0x0 F 

TpBL 

Top Back Left 

0x10 

TpBR 

Top Back Right 

0x11 

TpSiL 

Top Side Left 

0x12 

TpSiR 

Top Side Right 

0x13 

TpBC 

Top Back Center 

0x14 i 

BtFC 

Bottom Front Center 

0x15 

BtFL 

Bottom Front Left 

0x16 

BtFR 

Bottom Front Right 

0x17 

FLw 

Front Left Wide 

0x18 

FRw 

Front Right Wide 

0x19 

LS 

Left Surround 

0x1 A 

RS 

Right Surround 

0x1 B 


reserved 

0x1 C 


reserved 

0x1 D 


reserved 

0x1 E 


reserved 

0x1 F 


Table 34 Speaker Placement 


NOTE: 

F: indicates speakers forward of the primary listening position 

B: indicates speakers behind the primary listening position 

Si: indicates speaker to the side of the primary listening position 

Tp: indicates speakers above the normal seating position of the listeners 

Bt: indicates speakers below the normal seating position of the listeners 

TpC: is directly over the primary listening position. All speakers are assumed to be generally pointing at 
the primary listening position. 

Data Byte 4 contains information that describes how various speaker locations are allocated to 
transmission channels. Channel allocation is shown in Table 35 (see Annex K for additional information 
concerning audio channel allocation relationships between CTA-861 and other standards). 

Codes OxFE and OxFF in Data Byte 4 designate an alternate delivery order of the L-PCM audio, 
described in Section 6.6.3 or 6.6.4. 


78 




CTA-861-G 




2 

1 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 

FR 

FL 
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CA 

(binary) 

CA 

(hex) 

Channel Number 

m 

m 

■ 

m 

m 

■ 

m 

m 

0x2C 

TpC 

TpFC 

RS 

LS 

FC 

- 

FR 

FL 

0 


m 


n 

m 


m 

0x2 D 

TpC 

TpFC 

RS 

LS 

FC 

LFE1 

FR 

FL 

0 


m 


m 

m 

m 


0x2 E 

TpFR 

TpFL 

RS 

LS 

FC 

- 

FR 

FL 

0 


m 


m 

m 

m 

■ 

0x2 F 

TpFR 

TpFL 

RS 

LS 

FC 

LFE1 

FR 

FL 

0 


m 

■ 





0x30 

FRW 

FLW 

RS 

LS 

FC 

- 

FR 

FL 

0 

m 

m 

m 

m 

m 

m 

■ 

0x31 

FRW 

FLW 

RS 

LS 

FC 

LFE1 

FR 

FL 

0 

0 

i 

i 

0 

0 

i 

0 

0x32 

Reserved 



1 

1 

i 

i 

1 

1 

0 

1 

OxFD 

1 

1 

i 

i 

1 

1 

1 

0 

OxFE 

Channels delivered according to the Speaker Mask (see 
section 6.6.3) 

1 

1 

i 

i 

1 

1 

1 

1 

OxFF 

Channels delivered according to Channel Index (see 
section 6.6.4) 


Table 35 Audio InfoFrame Data Byte 4 


The Sink’s speaker allocation is not always the same as that contained within the Source’s audio. In this 
case, the Source should down mix the audio in order to properly meet the Sink’s speaker configuration. In 
actual implementations, all down-mix coefficients are equally attenuated to prevent calculation overflows. 
The total sound level becomes lower after down-mixing. For this reason, the Level Shift Value should also 
be transmitted to the Sink to insure the proper sound level is achieved. 

Data Byte 5 contains Level Shift Information, a Down-mix Inhibit Flag, and LFE playback level 
information. 

The values of attenuation associated with the Level Shift Values (LSV0-LSV3) are shown in Table 36. 


LSV3 

LSV2 

LSV1 

LSV0 

Level Shift Value 

0 

0 

0 

0 

OdB 

0 

0 

0 

1 

IdB 

0 

0 

1 

0 

2dB 

0 

0 

1 

1 

3dB 

0 

1 

0 

0 

4dB 

0 

1 

0 

1 

5dB 

0 

1 

1 

0 

6dB 

0 

1 

1 

1 

7dB 

1 

0 

0 

0 

8dB 

1 

0 

0 

1 

9dB 

1 

0 

1 

0 

10dB 

1 

0 

1 

1 

11dB 

1 

1 

0 

0 

12dB 

1 

1 

0 

1 

13dB 

1 

1 

1 

0 

14dB 

1 

1 

1 

1 

15dB 


Table 36 Audio InfoFrame Data Byte 5, Level Shift Value 

The Down-mix Inhibit Flag is shown in Table 37. 
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DMJNH 

Describes whether the down mixed stereo output is permitted or not. 

0 

Permitted or no information about any assertion of this 

1 

Prohibited 


Table 37 Audio InfoFrame Data Byte 5, Down-mix Inhibit Flag 


The LFE playback level information shown in Table 38 can be used to communicate one element of 
techniques used to balance low frequency audio information when audio is presented in a variety of 
speaker configurations combining speakers and subwoofers. One such technique uses a 10dB boost to 
bring low frequency information in the LFE channel of 5.1 channel audio systems in acoustical balance 
with the low frequency information present at other speakers. This table is a simple way of communicating 
from Source-to-Sink that this element of low frequency balancing has been employed. If audio data does 
not contain a LFE signal, then the LFEPBL field shall be ignored. 


LFEPBL1 

LFEPBLO 

Describes what value is used for LFE playback level comparing with 
other channel signal. 

0 

0 

Unknown or refer to other information 

0 

1 

0 dB playback 

1 

0 

+ 10 dB playback 

1 

1 

Reserved 

NOTE—The Source may set the LFEPBL fields according to encoding rules of source content. Typically 
the Audio/Visual content use +1 OdB and Audio contents use OdB. The Sink may adjust the LFE signal 
level and not the total output level for subwoofer in down mixing case. If the audio data does not contain 
a LFE signal, the LFEPBL field shall be ignored. 


Table 38 Audio InfoFrame Data Byte 5, LFE Playback Level Information 


6.6.3 Delivery According to the Speaker Mask (Byte 4 = OxFE) 

Data Bytes 6 to 8 of the InfoFrame shown in Table 29 correspond to the SPM Bytes defined in Table 91 
and these bytes constitute the Speaker Mask. The source shall not declare channels in the InfoFrame 
that were not declared as available in the RCD. All channels declared in the InfoFrame shall be present in 
the audio delivery. 

In the SPM of the RCD (Table 91), many of the flags describe a pair of speakers (e.g. FL/FR), but some 
describe a single speaker (e.g. LFE1). When a source device is preparing audio for a room described in 
this manner, both speakers of a pair are always assumed to be present. 

For systems conforming to ISO 60958 [44], speaker feeds are always packed in channel pairs. For 
example in a 5.1 speaker system, LFE1 and FC are packed together in a L-PCM transmission. 

The ordering of the L-PCM channels feeding into the speakers shall be according to the following rules: 

1. Channels shall be sent consecutively in the order indicated in the SPM portion of the Room 
Configuration Descriptor Data Block, starting from bit 0, byte 1. 

2. Channel pairs shall always be sent together in the order of Left/Right 

3. Single channels shall be sent in the order of the first flag/next flag, e.g. LFEI/Center. 

4. If one or more channel pairs exists between two single channels, then the second single channel 
shall be brought forward to fill the vacancy ahead of the pairs. 

5. If an odd number of channels are being presented, then an inactive channel shall occupy the 
second channel of the channel pair carrying the single channel. 

Example: 

A source is sending the following channels: 

FL, FR, LFE1, FC, BL, BR, BC, TpFL, TpFR, LFE2 
The order of the channel pairs shall be as follows: 

FL/FR, 
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LFE1/FC, 

BL/BR, 

BC/LFE2, 

TpFL/TpFR 


6.6.4 Delivery by Channel Index (Byte 4 = OxFF) 

A Source shall only deliver audio data by channel index when a Speaker Location Data Block is available 
for all channels being utilized by the Source. 

If the delivery by Channel Index is used, it will be used exclusively, and delivery by speaker mask (as 
described in 6.6.3) will not be used. 

When Delivery by Channel Index is being used, Data Bytes 6, 7, 8 and 9 in the Audio InfoFrame, shown 
in Table 30, indicate which channels are being delivered. Bits CID00 to CID31 correspond to Channel 
Index 0 to Channel Index 31 respectively, as assigned in the Speaker Location Descriptors. 

The Source shall only deliver audio to Channel Indices that were declared in a Speaker Location Data 
Block. For each Channel Index that is represented in the audio transmission, the corresponding CID flag 
of the InfoFrame shall be set to 1. All other CID flags shall be set to 0. 

The ordering of the L-PCM channels in the audio transmission shall directly correspond to the Channel 
Index from the lowest value to the highest, not make any exception for paired (L/R) channels, and only 
include channels indicated as Active in the corresponding Speaker Location Descriptor (see Table 93). 

6.6.5 Additional Audio InfoFrame Information 

The value of the LFEPBL field, in Audio InfoFrame Data Byte 5, shall apply to all LFE channels in use 
(i.e., LFE1 and LFE2). 


6.7 MPEG Source InfoFrame 

The MPEG Source InfoFrame describes aspects of the compressed video stream that were used to 
produce the uncompressed video. In many cases, the compressed source is MPEG2, although this 
InfoFrame can be applied to any similar compressed format. Some Sinks may use this information to 
improve the displayed Picture. 

NOTE— Implementation of the MPEG Source InfoFrame is not recommended due to issues that 
have been reported and not resolved. The information contained in this section is reserved for 
future use and enhancement. 

Transmission of this information by the Source is optional. Use of this information by the Sink is also 
optional. 

If the Source supports the transmission of the MPEG Source InfoFrame and if it determines that the Sink 
is capable of receiving the MS InfoFrame (i.e., the Sink has included CTA Extension Version 3 in EDID), 
then this information should be sent once per Video Frame when applicable. The data applies to the next 
full frame of video data. 

The format of the MPEG Source InfoFrame is shown in Table 39. 
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InfoFrame Type Code 

InfoFrame Type = 0x05 

InfoFrame Version Number 

Version = 0x01 

Length of MPEG Source 
InfoFrame 

Length of MPEG Source InfoFrame (10) 

Data Byte 1 

MB#0 (MPEG Bit Rate: Hz Lower Upper) 

Data Byte 2 

MB#1 

Data Byte 3 

MB#2 

Data Byte 4 

[ MB#3 ( U 

pper Byte ) [ 

Data Byte 5 

F57=0 

F56=0 

F55=0 

FRO 

F53=0 

F52=0 

MF1 

MF0 

Data Byte 6 

F67=0 

F66=0 

F65=0 

F64=0 

F63=0 

F62=0 

F61=0 

F60=0 

Data Byte 7 

F77=0 

F76=0 

F75=0 

F74=0 

F73=0 

F72=0 

F71=0 

F70=0 

Data Byte 8 

F87=0 

F86=0 

F85=0 

F84=0 

F83=0 

F82=0 

F81=0 

F80=0 

Data Byte 9 

F97=0 

F96=0 

F95=0 

F94=0 

F93=0 

F92=0 

F91=0 

F90=0 

Data Byte 10 

FI 07=0 

FI 06=0 

FI 05=0 

FI 04=0 

FI 03=0 

FI 02=0 

F101=0 

FI 00=0 


Table 39 MPEG Source InfoFrame format 


Data Bytes 1-4 give the MPEG bit rate. The MPEG Bit Rate is stored as a 32-bit number and is expressed 
in Hertz. MB#0 contains the least significant byte while MB#3 contains the most significant byte. If the 
MPEG Bit Rate is unknown or this field does not apply, then all of the bits in Data Bytes 1 -4 shall be set to 
0 . 

Example: 

10 Mbps -> 10,000,000 Hz (dec.) -> 0x00989680 Upper ... Lower Byte 
Byte 1 MB#0 0x80 Lower Byte 

Byte 2 MB#1 0x96 
Byte 3 MB#2 0x98 
Byte 4 MB#3 0x00 Upper 

MF1 and MF0 in Data Byte 5 (see Table 40) designate whether the current field/frame was generated 
from an I, B, or P picture from the source MPEG stream. If this is unknown or does not apply, then the 
field shall be set to “unknown.” 

In some cases, the Source creates 60 field/second video from 24 frames/second source material. 3:2 
pull-down is commonly used. FRO can be used to designate whether a field is a repeated field or not. The 
Sink can use this information to improve the picture. If 3:2 pull-down does not apply to the current video 
decoding, then all of the fields/frames should be marked as “New field.” 


MF1 

MF0 

MPEG Frame 

0 

0 

Unknown (No Data) 

o 

1 

1 Picture 

1 

0 

B Picture 

1 

1 

P Picture 


FRO 

Field Repeat 
(for 3:2 pull-down) 

o 

New field (Picture) 

1 

Repeated Field 


Table 40 MPEG Source InfoFrame Data Byte 5 


6.8 NTSC VBI InfoFrame 

The NTSC VBI InfoFrame provides for the carriage of SCTE 127 [28] payloads containing VBI data. 
Transmission of this information by the Source is optional. Use of this information by the Sink is also 
optional. However, when present, Sinks can extract this information for direct use, or when analog NTSC 
outputs are present, regenerate relevant VBI data along with the video and audio. 
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This InfoFrame should be sent once per Video Frame when applicable. The data applies to the next full 
frame of video data. 

The format of the NTSC VBI InfoFrame is shown in Table 41. 


InfoFrame Type Code 

InfoFrame Type = 0x06 

InfoFrame Version Number 

Version = 0x01 

Length of NTSC VBI 

Length of NTSC VBI InfoFrame - total number of bytes following 

this field 

Data Bytes 1 ...Length 

The PES data fieldf) structure of SCTE 127, Table 2 [281 


Table 41 NTSC VBI InfoFrame 


The stuffing_bytes should be omitted before transmission by the Source. 

In order to maximize the possibility of operation with existing silicon, Sources should constrain the NTSC 
VBI InfoFrame’s payload to 27 bytes or less (e.g., a 31-byte HDMI InfoFrame less 3-byte header and 1- 
byte checksum leaves 27 bytes for payload). This means the PES_data_field() structure would be 
constrained (modified if necessary) to 27 bytes. NABTS (which requires 37 bytes) should not be encoded. 

Note: 27-byte payload is adequate, for example, for two fields of AMOL96 and one field of TVG2X per 
frame. 


6.9 Dynamic Range and Mastering InfoFrame 

The Dynamic Range and Mastering InfoFrame carries data such as the EOTF and the Static Metadata 
associated with the dynamic range of the video stream. 

If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it 
determines that the Sink is capable of receiving that information, the Source shall send the Dynamic 
Range and Mastering InfoFrame once per Video Field while it is sending data associated with the 
dynamic range of the video stream. The Source shall not send a Dynamic Range and Mastering 
InfoFrame to a Sink that does not have at least one of the ET_r? bits set to ‘1 ’. 

The format of the Dynamic Range and Mastering InfoFrame is shown in Table 42. 


InfoFrame Type Code 

InfoFrame Type = 0x07 

InfoFrame Version 
number 

Version=0x01 

Length of Info Frame 

Length of following HDR Metadata InfoFrame 

Data Byte 1 

FI 7=0 

FI 6=0 

FI 5=0 

FI 4=0 

F13=0 

EOTF (3 bits) 

Data Byte 2 

F27=0 

F26=0 

F25=0 

F24=0 

F23=0 

Static_Metadata_ 

Descriptor ID (3 bits) 

Data Byte 3 

Static Metadata 1 

Descriptor i 


1 




Table 42 Dynamic Range and Mastering InfoFrame 


84 
























CTA-861-G 


Data Byte 1 EOTF identifies the Electro-Optical Transfer Function (EOTF) used in the stream. 


EOTF 

EOTF of stream 

0 

Traditional gamma - SDR Luminance Range j 

1 

Traditional gamma - HDR Luminance Range 

2 

SMPTE ST 2084 [401 

3 

Hybrid Log-Gamma (HLG) based on ITU-R 

BT.2100-0 [501 

4- 7 

Reserved for future use 


Table 43 Data Byte 1 - Electro-Optical Transfer Function 


“Traditional Gamma” indicates that the EOTF used in the video stream is consistent with the requirements 
in CTA-861. If the Colorimetry bits CO and Cl in the AVI InfoFrame are both zero (indicating “No Data”), 
then the transfer function shall be consistent with the requirements in section 5.1, “Default Encoding 
Parameters”. If either of bits CO and Cl in the AVI Info Frame are non-zero, then the transfer function 
shall be consistent with the colorimetry standard indicated by the Colorimetry (CO and Cl) and Extended 
Colorimetry (ECO to EC2) bits in the AVI InfoFrame. See section 5.3, “Transfer Characteristic (e.g., 
gamma correction)” for more information on transfer functions for supported colorimetry standards. The 
SMPTE ST 2086 [41] metadata contained in Bytes 3-22 of Table 45 Static Metadata Descriptor Type 1 
may be used by the Source to provide information about the mastering display color volume 
characteristics associated with the video stream. 

If “Traditional Gamma - SDR Luminance Range” is indicated, then the maximum encoded luminance is 
typically mastered to 100 cd/m 2 . 

If “Traditional Gamma - HDR Luminance Range” is indicated, then the maximum encoded luminance is 
understood to be the maximum luminance of the Sink device. 

Data Byte 2 Static_Metadata_Descriptor_ID identifies the structure used in Data Byte 3 and higher. 


Static_Metadata_ 

Descriptors 

Metadata Descriptor 

0 

Static Metadata Type 1 

1 -7 

Reserved for future use 


Table 44 Data Byte 2 - Static_Metadata_Descriptor_ID 


6.9.1 Static Metadata Type 1 

When Static_Metadata_Descriptor_ID = 0, Static_Metadata_Descriptor uses the structure defined in 
Table 45 that was defined at the request of the Blu-ray Disc Association, see [104]. 
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Data Byte number 

Contents 

Group 

Data Byte 3 

display primaries x[0], LSB 

1 

Data Byte 4 

display primaries x[01, MSB 

Data Byte 5 

display primaries y[0], LSB 

Data Byte 6 

display primaries y[0], MSB 

Data Byte 7 

display primaries xfll, LSB 

Data Byte 8 

display primaries x[1], MSB 

Data Byte 9 

display primaries y[1], LSB 

Data Byte 10 

display primaries y[1], MSB 

Data Bytel 1 

display primaries x[2], LSB 

Data Byte 12 

display primaries x[21, MSB 

Data Byte 13 

display primaries y[2], LSB 

Data Byte 14 

display primaries y[2], MSB 

Data Byte 15 

white point x, LSB 

2 

Data Byte 16 

white point x, MSB 

Data Byte 17 

white point y, LSB 

Data Byte 18 

white point y, MSB 

Data Byte 19 

max display mastering luminance, LSB 

3 

Data Byte 20 

max display mastering luminance, MSB 

Data Byte 21 

min display mastering luminance, LSB 

4 

Data Byte 22 

min display mastering luminance, MSB 

Data Byte 23 

Maximum Content Light Level, LSB 

5 

Data Byte 24 

Maximum Content Light Level, MSB 

Data Byte 25 

Maximum Frame-average Light Level, LSB 

6 

Data Byte 26 

Maximum Frame-average Light Level, MSB 


Table 45 Static Metadata Descriptor Type 1 


Data Bytes 3-22 contain the Display Mastering data defined in SMPTE ST 2086 [41]. 

Data Bytes 3-18 are coded as unsigned 16-bit values in units of 0.00002, where 0x0000 represents 
zero and 0xC350 represents 1.0000. 

Data Bytes 3-14 describes the chromaticity of the Red, Green and Blue color primaries of the mastering 
display, 

All possible mappings of the chromaticity of Red, Green and Blue color primaries to indices 0,1, and 2 
are allowed and shall be supported by the sink. 

The correspondence between Red, Green and Blue color primaries and indices 0, 1, or 2 are determined 
by the following relationship: 

The Red color primary corresponds to the index of the largest display_primaries_x[] value. 

The Green color primary corresponds to the index of the largest display_primaries_y[] value. 

The Blue color primary corresponds to the index with neither the largest display_primaries_y[] value nor 
the largest display_primaries_x[] value. 

Data Bytes 19-20 specify a value for the max_display_masteringjuminance. This value is coded as an 
unsigned 16-bit value in units of 1 cd/m 2 , where 0x0001 represents 1 cd/m 2 and OxFFFF represents 
65535 cd/m 2 . 

Data Bytes 21 - 22 specify a value for the min_display_mastering_luminance. This value is coded as an 
unsigned 16-bit value in units of 0.0001 cd/m 2 , where 0x0001 represents 0.0001 cd/m 2 and OxFFFF 
represents 6.5535 cd/m 2 . 


86 




CTA-861-G 


Data Bytes 23 - 24 contain the Maximum Content Light Level (MaxCLL). This value is coded as an 
unsigned 16-bit value in units of 1 cd/m 2 , where 0x0001 represents 1 cd/m 2 and OxFFFF represents 
65535 cd/m 2 . 12 The algorithm used to calculate MaxCLL is defined in Annex P section P.1. 

Data Bytes 25 - 26 contain the Maximum Frame-Average Light Level (MaxFALL). This value is coded as 
an unsigned 16-bit value in units of 1 cd/m 2 , where 0x0001 represents 1 cd/m 2 and OxFFFF represents 
65535 cd/m 2 . 13 The algorithm used to calculate MaxFALL is defined in Annex P section P.2. 

The data in Data Bytes 3-26 are arranged into groups, as indicated in Table 45 Static Metadata 
Descriptor Type 1 above. When all of the Data Bytes in a group are set to zero, then the Sink shall 
interpret the data for that group as unknown 14 . It is permissible to send a Static Metadata Descriptor 
(Data Bytes 3 through n) containing a subset of data that is constructed with partial zeroes. 

If a Source does not have SMPTE ST 2086 [41] metadata to send, then Data Bytes 3-22 shall be 
populated with zeroes to indicate the data is not provided. 


6.10 Extended InfoFrame 

The Extended InfoFrame is intended to carry larger amounts of data than is allowed by the InfoFrame 
mechanism described in sections 6.1 to 6.9. 

The content of the Extended InfoFrame is shown in Table 46: 


Extended InfoFrame Type Code 

Extended InfoFrame Type LSB 

Extended InfoFrame Type MSB 

Length (n) of Extended InfoFrame 

Length of following Extended InfoFrame Data LSB 

Length of following Extended InfoFrame Data MSB 

Data Byte 1 

Extended InfoFrame Data Byte 1 



Data Byte n 

Extended InfoFrame Data Byte n 


Table 46 Extended InfoFrame 


Extended InfoFrame Type Code - a 2-byte number identifying the data carried in this Extended 
InfoFrame. Extended InfoFrame Type Codes are shown in Table 47: 


12 For MaxCLL, the unit is equivalent to cd/m 2 when the brightest pixel in the entire video stream has the chromaticity 
of the white point of the encoding system used to represent the video stream. Since the value of MaxCLL is 
computed with a max() mathematical operator, it is possible that the true CIE Y Luminance value is less than the 
MaxCLL value. This situation may occur when there are very bright blue saturated pixels in the stream, which may 
dominate the max(R,G,B) calculation, but since the blue channel is an approximately 10% contributor to the true 
CIE Y Luminance, the true CIE Y Luminance value of the example blue pixel would be only approximately 10% of 
the MaxCLL value. 

13 For MaxFALL, the unit is equivalent to cd/m 2 when the maximum frame average of the entire stream corresponds 
to a full-screen of pixels that has the chromaticity of the white point of the encoding system used to represent the 
video stream. The frame-average computation used to compute the MaxFALL value is performed only on the active 
image area of the image data. If the video stream is a "letterbox" format (e.g. where a 2.40:1 aspect ratio is put 
inside a 16:9 image container with black bars on the top and bottom of the image), the black bar areas are not part 
of the active image area and therefore are not included in the frame-average computation. This allows the 
MaxFALL value to remain an upper bound on the maximum frame-average light level even if image zooming or 
pan/scan is performed as a post-processing operation. 

14 For MaxCLL and MaxFALL, this may occur when information about the content light level has not been, or cannot 
be, provided - for example, content that is rendered or broadcast in real-time, or pre-processed content that was 
delivered without information about the content light level. 
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Value 

Extended InfoFrame Type 

0x0000 

Reserved 

0x0001 

HDR Dynamic Metadata according to the syntax 
specified in Annex R 

0x0002 

HDR Dynamic Metadata carried in Supplemental 
Enhancement Information (SEI) messages 
according to ETSI TS 103 433 [53] 

0x0003 

HDR Dynamic Metadata carried in Colour 
Remapping Information SEI message according 
to ITU-T H.265 [55] 

0x0004 

HDR Dynamic Metadata carried according to the 
syntax specified in Annex S 

All other values 

Reserved 


Table 47 Extended InfoFrame Type Codes 


Length of Extended InfoFrame - a 2-byte value indicating the length of the following Extended InfoFrame 
data. 

Data Byte 1 to n - The Extended InfoFrame Data identified by the Extended InfoFrame Type Code. 


6.10.1 HDR Dynamic Metadata Extended InfoFrame 

When the Extended InfoFrame Type Code is set to 0x0001,0x0002, 0x0003, or 0x0004, the Extended 
InfoFrame carries HDR Dynamic Metadata. The HDR Dynamic Metadata Extended InfoFrame contains 
the HDR Dynamic Metadata that may be carried in Supplemental Enhancement Information (SEI) 
messages. 

Figure 7 depicts the transfer timing and applicability of the HDR Dynamic Metadata Extended InfoFrame 
data relative to the video lines. The Metadata Transmission Window (MTW) is defined as the period of 
time beginning with the first Active Pixel of a Video Frame and ending with the final Blank Pixel of the final 
Blanking Line in a Vblank period. As shown by the arrow in Figure 7, HDR Dynamic Metadata 
transmitted during the MTW applies to the Active Pixels that immediately follow the MTW. Standards and 
specifications that incorporate CTA-861 may reduce the period of the MTW by delaying the start of the 
MTW and/or ending the MTW on an earlier Blanking Line. 


First Active Pixel of the Top Line 


First Active Pixel of the Top Line 



Figure 7 HDR Dynamic Metadata Transmission Window and Metadata Applicability 
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The HDR Dynamic Metadata Extended InfoFrames is shown in Table 48 below: 


Extended InfoFrame Type Code 

Extended InfoFrame Type LSB 

Extended InfoFrame Type MSB 

Length (n) of Extended InfoFrame 

Length of following Extended InfoFrame Data LSB 

Length of following Extended InfoFrame Data MSB 

Data Byte 1 

Application-specific Data 1 



Data Byte n 

Application-specific Data n 


Table 48 HDR Dynamic Metadata Extended InfoFrame common structure 


When Extended InfoFrame Type Code is set to 0x0001, the Application-specific data in Data Bytes 1-n is 
the Display Management Message Data that is specified in Annex R. 

When Extended InfoFrame Type Code is set to 0x0002, the Application-specific Data in Data Bytes 1 -n is 
a concatenation of the Supplemental Enhancement Information (SEI) messages described in the 
Annexes of ETSI TS 103 433 [53] in any order. The data bytes defining payloadType and payloadSize as 
defined in ITU-T H.264 [54] and ITU-T H.265 [55] are included in the Application-specific Data. 

When Extended InfoFrame Type Code is set to 0x0003, the Application-specific Data in Data Bytes 1 -n is 
the Colour Remapping Information (CRI) Supplemental Enhancement Information (SEI) message 
described in ITU-T H.265 [55]. The data bytes defining payloadType and payloadSize as defined in ITU-T 
H.265 [55] are included in the Application-specific Data. 

When Extended InfoFrame Type Code is set to 0x0004, the Application-specific data in Data Bytes 1-n is 
the Dynamic Metadata for Color Volume Transform - Application #4 of SMPTE 2094-40 [58] standard that 
is specified in Annex S. 

For the above Extended InfoFrame Type Codes (0x0001,0x0002, 0x0003, and 0x0004), the data 
contained in the HDR Dynamic Metadata Extended InfoFrame applies to the Active Pixels that follow the 
MTW. 

If the Source supports transmission of a type of HDR Dynamic Metadata Extended InfoFrame (as 
indicated by the relevant Extended InfoFrame Type) and if it determines that the Sink is capable of 
receiving that information, the Source may send the HDR Dynamic Metadata Extended InfoFrame in 
conjunction with the video encoded according to the rules of the Extended InfoFrame Type. 

A Source shall not send an HDR Dynamic Metadata Extended InfoFrame containing an Extended 
InfoFrame Type 0x001,0x002, 0x003, or 0x004 to a Sink that does not indicate support for that Extended 
InfoFrame Type in the Sink’s HDR Dynamic Metadata Data Block. A Source shall not send more than 
one type of HDR Dynamic Metadata Extended InfoFrame within the same MTW. 

When used, the HDR Dynamic Metadata Extended InfoFrame shall be sent every MTW and shall contain 
the data relevant to the immediately following Active Video period. Data in each HDR Dynamic Metadata 
Extended InfoFrame may be the same as that sent in previous HDR Dynamic Metadata Extended 
InfoFrames. 

If the Source is sending an HDR Dynamic Metadata Extended InfoFrame according to the above rules, 
then it shall not also send Dynamic Range and Mastering InfoFrames. 
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7 EDID Data Structure 

Extended Display Identification Data (EDID) was created by VESA to enable plug and play capabilities of 
displays (Sinks). This data, which is stored in the Sink, describes Video Formats that the DTV (display) is 
capable of receiving and rendering. The information is supplied to the Source, over the interface, upon 
the request of the Source. The Source then chooses its output format, taking into account the format of 
the original video stream and the formats supported by the Sink. Format conversions necessary to supply 
video to the Sink should be determined according to recommendations in Annex F. 

The EDID data structures version 1, revision 3 [9] and newer are known as Enhanced EDID (E-EDID). 
Sources should interpret and Sinks should implement the EDID data structure according to the VESA E- 
EDID Implementation Guide [80]. Sink implementers should verify a Sink’s EDID data structure using the 
VESA E-EDID Verification Guide [84]. The Sink shall support E-DDC [98] as the method of transporting 
EDID information. A Source shall be capable of using E-DDC [98] to read the entire EDID since critical 
information may not otherwise be readable if the Sink contains a large EDID. 

Some Sinks may contain more than 2 blocks of EDID data. For example, the Sink may include a second 
CTA-861 Extension Block, a VESA DI-EXT Block (as defined in VESA DI-EXT [79]) or a VTB-EXT Block 
(as defined in VESA VTB-EXT [87]). In this case the Sink is required to support E-DDC Addressing (using 
the Segment Pointer) as defined in VESA E-DDC [98]. It is also recommended that the Source be 
capable of reading and parsing more than 2 blocks of EDID data. For more information on E-DDC 
addressing refer to the VESA E-DDC Standard [98]. 

The base EDID (Block 0) contains both version and revision numbers. The version number indicates the 
data structure of the base EDID, which remains backwards compatible as the revision number changes. 
Therefore, a Source should continue parsing a recognized structure version - even if it encounters an 
unexpected revision number. 

The Sink shall protect its EDID from accidental corruption resulting from I2C errors by write-protecting its 
contents. 

See Annex A and Annex D for an example EDIDs. 

7.1 Use of CTA Extensions 

Two of the four 18-byte descriptor slots contained in EDID Block 0 are designated for a Monitor Range 
Limits Descriptor and a Monitor Name Descriptor. Users of CTA-861 should note that future alternate 
usage of these descriptors is possible, including replacing them with additional Detailed Timing 
Descriptors; therefore, dependency upon data in these descriptors should be avoided. Consequently, the 
E-EDID standard provides a method for including only two Detailed Timing Descriptors. To accommodate 
additional Detailed Timing Descriptors, the CTA Extension has been defined. The tag (0x02) for this 
extension, previously reserved within VESA, has now been assigned to CTA for the purposes of CTA- 
861 . Therefore, further changes to this structure are under the control of CTA. It is referred to in CTA-861 
as the CTA Extension. 

Three versions of the CTA Extension exist. If more than one CTA Extension is included in EDID, they 
shall all be the same version. 

To maintain backward compatibility, newer versions of the CTA Extension include all of the fields that 
were present in the previous versions. Additionally, length fields are provided on internal data structures 
to convey block size and to aid the Source in interpreting the data. Having block sizes should help Source 
devices move from block-to-block, when blocks contain corrupt or Vendor-Specific data. Future versions 
of the CTA Extension are expected to have the version number incremented and be backward compatible 
with previous versions. A current generation Source is capable of parsing these future EDIDs exactly as it 
does existing EDIDs, if it ignores the version number. Sources should continue parsing the EDID 
structure even if an unexpected version number is encountered. 
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CTA Extension Version 1 only provides a way to supply extra Detailed Timing Descriptors. It is still 
permitted to be used for some Sinks (e.g., limited format DVI displays) but Version 3 is more applicable 
for most devices. 

CTA Extension Version 2 is no longer supported and shall not be included in Sinks. 

CTA Extension Version 3 includes all of the fields and capabilities of Versions 1 & 2, but also includes the 
ability to specify any of the CTA Video Formats using “CTA Short Video Descriptors.” It provides the 
ability for the Sink to specify what types of advanced audio it supports using “CTA Short Audio 
Descriptors.” It also provides a way for the Sink to specify its speaker configuration. This information is 
complementary to the speaker channel allocation information that is sent in the Audio InfoFrame. 

If a Sink supports any Video Format with a format code greater than 7, YCbCr color space, InfoFrames, 
or digital audio (e.g., is an HDMI monitor), then it shall include the version 3 (or higher) CTA Extension in 
its EDID data structure. 

7.2 Describing Video Formats in EDID 

Two methods of describing Video Formats are used in CTA-861: Detailed Timing Descriptors and CTA 
Short Video Descriptors. 

The Sink shall declare support for all of the DTV formats that it supports in EDID block 0 or in the CTA 
Extension(s). The 640x480@60Hz flag, in the Established Timings area, shall always be set, since the 
640x480p format is a mandatory default timing. 

When using CTA Extension Version 1, all of the CTA Video Formats listed in E-EDID are described using 
Detailed Timing Descriptors. No matter which CTA Extension is used, there is also room for two Detailed 
Timing Descriptors in EDID Block 0. CTA Extension Version 3 can include a combination of Detailed 
Timing Descriptors and Short Video Descriptors. 

If a Version 3 CTA Extension has been included in EDID, all CTA Video Formats shall be advertised 
using Short Video Descriptors, even if they are also advertised using the Detailed Timing Descriptors (see 
7.2.1). 

Even though Short Video Descriptors are available in the Version 3 CTA Extension, there is still a need to 
use Detailed Timing Descriptors if full backward compatibility with legacy Sources is desired. Formats 
with video ID codes of 2 to 5 and 17 to 20 should be advertised using the Detailed Timing Descriptors for 
any Video Formats that the DTV designer wishes to guarantee are available to Sources that cannot 
interpret the Short Video Descriptors and that require Detailed Timing Descriptors for proper operation. If 
sufficient room is not available in the first two blocks of the EDID for all of the supported Video Formats, 
the DTV designer may choose to declare support for some of the formats in Short Video Descriptors only. 

7.2.1 Use of EDID Detailed Timing Descriptors 

As required in Section 4, a DTV that declares it is capable of displaying a Video Timing with a vertical 
frequency that is either an integer multiple of 6 Hz or an integer multiple of 6 Hz adjusted by a factor of 
1000/1001 shall be capable of displaying both versions of the Video Timing. DTVs capable of displaying 
59.94/60 Hz versions of Video Timings shall declare in the EDID structure the 60Hz version of the Video 
Timing for all Video Formats, except the 240-line and 480-line formats, which shall declare 59.94Hz 
version of the Video Timing. 

All DTDs and SVDs shall be listed in order of priority; meaning that the first is the one that the display 
manufacturer has identified as optimal. 

Note that the EDID Detailed Timing Descriptor allows for the designation of an interlaced format. 

However, there are no provisions to specify separate vertical blanking/sync for Field 1 and Field 2. 
Therefore, for the purposes of CTA-861, the following rules apply for interlaced formats: 
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a) The Field 1 Vertical Blanking Interval shall equal the Vertical Blanking Lines in the Detailed Timing 
Descriptor. 

b) The Field 2 Vertical Blanking Interval shall equal the Vertical Blanking Lines in the Detailed Timing 
Descriptor + 1. 

c) The Field 1 Vertical Sync Offset shall equal the Vertical Sync Offset in the Detailed Timing Descriptor. 

d) The Field 2 Vertical Sync Offset shall equal the Vertical Sync Offset in the Detailed Timing Descriptor 
+ 1 / 2 . 

A Sink capable of receiving a Video Format with a Video Identification Code greater than 7 or capable of 
receiving a Dual-Aspect Ratio Timing shall declare different Detailed Timing Descriptors in its EDID for 
each supported Video Timing with a different Picture Aspect Ratio. The vertical and horizontal image size 
parameters in the EDID shall contain numbers that describe the aspect ratio of the displayed video 
(actual dimensions are preferred, but not required). 

A special interlaced Video Timing exists (see Figure 5) that modifies the Field 2 Vertical Blanking Interval 
(b) and Vertical Sync Offset (d) values presented here. When all DTD parameters match those of Video 
Identification Code 39 (see Table 49) and a SVD indicating support for code 39 Video Format also exists, 
the Field 2 Vertical Blanking Interval (b) and Vertical Sync Offset (d) shall instead equal the DTD's 
"Vertical Blanking Lines" and the DTD's "Vertical Sync Offset" -1/2, respectively. 


Byte 

# 

Data 

Hex Dec 

Description 

Remarks 

1 

0x20 

32 

Pixel Clock 

72.00 MHz 

2 

0x1 C 

28 

3 

0x80 

128 

H Active 

1920 pixels 

4 

0x80 

128 

H Blanking 

384 pixels 

5 

0x71 

113 

H Active: H Blanking 


6 

0x1 C 

28 

V Active 

540 lines 

7 

0x55 

85 

V Blanking 

85 lines 

8 

0x20 

32 

V Active: V Blanking 


9 

0x20 

32 

H Sync Offset 

32 pixels 

10 

0xA8 

168 

H Sync Pulse Width 

168 pixels 

11 

0x75 

117 

VS Offset: VS Pulse 
Width 

23 lines, 5 lines 

12 

0x04 

4 

HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


13 

(any) 

(any) 

H Image Size 

(any) 

14 

(any) 

(any) 

V Image Size 

(any) 

15 

(any) 

(any) 

H&V Image Size 


16 

0x00 

0 

H Border 

0 lines 

17 

0x00 

0 

V Border 

0 pixels 

18 

0x9A, 
0x9 B, 
OxBA, 
OxBB, 
OxDA, 
OxDB, 
OxFA, 
or 

OxFB 

154, 

155, 
186, 
187, 
218, 
219, 
250, 
or 

251 

Flags 

Interlaced, digital separate, 
Vsync polarity is negative, 
Hsync polarity is positive 
(NOTE: stereo mode bits 0, 

5, & 6 may have any value) 


Table 49 Video Timing Code 39 Detailed Timing Descriptor 


Examples of Detailed Timing Descriptors for the Video Formats are contained in A.2.10. 
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7.2.2 Order of Dual-Aspect Ratio Detailed Timing Descriptors 

A Sink that supports any Dual-Aspect Ratio Timing shall, in its EDID, list the DTD and SVD with the 
Preferred Picture Aspect Ratio before the DTD and SVD with the other Picture Aspect Ratio. Per Section 
4.1, a Sink is required to assume that any Video Field matching a Video Timing is to be displayed at the 
Preferred Picture Aspect Ratio unless it receives an alternate indication in an AVI InfoFrame. 

A Sink not capable of receiving AVI InfoFrames shall only declare Video Formats with different Video 
Timings in its EDID data structure unless the Sink declares it is capable of displaying a Video Timing in 
either Picture Aspect Ratio. 


7.2.3 Source Requirements and Recommendations 

It is strongly recommended that a Source provide an option of operating in Source Pass-through Mode. 
When operating in Source Pass-through Mode, the Source transmits the video to the Sink without 
performing any interlacing, deinterlacing, or scaling on the transmitted content. A Source operating in 
Source Pass-through Mode determines the supported Video Formats of the Sink and utilizes this 
information to ensure that it passes through only Video Formats supported by the Sink. If the Sink 
supports no corresponding Video Format, then some conversion is necessary; it is recommended that the 
conversion be to the first format in the EDID that the Source supports. Detailed recommendations for 
Sources and Sinks, plus examples of different conversions are illustrated in Annex F. Typically, PCs and 
game machines locally determine the resolution of the content rather than processing pre-recorded or 
broadcast content at a preset resolution. In these cases, it is recommended that the Source generate the 
content in the first format in the EDID that the Source supports. The Source shall read the EDID to 
determine if a specific format is supported. The Source shall only choose an output format listed in the 
EDID except in the following circumstances: 

1. The Source cannot find a format in the EDID, which it supports. 

2. The user manually overrides the automatic behavior. 


7.3 CTA Extension Version 1 

This version of the CTA Extension has been supplanted by Version 3 (see Section 7.5) and is not 
recommended for new designs. It only allows an EDID to supply extra Detailed Timing Descriptors. 

The CTA Extension in Table 50 follows the format described in Section 2.2.1.3 of VESA E-EDID Standard 
[9]. The EDID Extension Tag for this extension shall be 0x02. The first detailed timing (DTD) listed in the 
base EDID data structure is preferred. 
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Byte# 

Value 

Description 

Format 

0 

0x02 

Tag (0x02) 


1 

0x01 

Revision Number 


2 


Byte number offset of where 18-byte 
descriptors begin (typically Detailed 
Timing Descriptors) 

d = offset for the byte following the 
reserved data block. If no data is 
provided in the reserved data block, 
then d=A. If no DTDs are provided, 
then d= 0. 

3 


Reserved 

Set to 0x00 

4 


Start reserved data block 

This section was previously i 

reserved for 8 byte timing 
descriptors but is currently a 
reserved data block. 

d -1 


End of reserved data block. 

d 


Start of 18-byte descriptors 

See Section 3.10.2 of VESA E-EDID 
Standard [9] 

d+(18*n)-1 


End of 18-byte descriptors where n is 
the number of descriptors included 

d+(18*n) 

0x00 

Beginning of Padding 


126 

0x00 

End of Padding 

127 


Checksum 

OxXX = This byte should be 
programmed such that a one-byte 
checksum (add all bytes together) of 
the entire 128 byte block equals 

0x00. 


Table 50 CTA Extension Version 1 (supplanted by Version 3) 
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7.4 CTA Extension Version 2 

CTA Extension Version 2 is deprecated and shall not be included in Sinks. See Table 51. 


Byte # 

Value 

Description 

Format 

0 

0x02 

Tag (0x02) 


1 

0x02 

Revision Number 


2 


Byte number offset d where 18-byte 
descriptors begin (typically Detailed 
Timing Descriptors) 

d = offset for the byte following the 
reserved data block. If no data is 
provided in the reserved data block, 
then c/=4. If d=0, then no detailed 
timing descriptors are provided and no 
data is provided in the reserved data 
block collection. 

3 


Total number of native Detailed Timing 
Descriptors in entire E-EDID structure. 
Also, indication of underscan support, 
audio support, and support of YCbCr is 
included 

bit 7 (underscan) = 1 if Sink 
underscans IT Video Formats by 
default. 

bit 6 (audio) = 1 if Sink supports Basic 
Audio. 

bit 5 (YCbCr 4:4:4) = 1 if Sink 
supports YCbCr 4:4:4 in addition to 

RGB. 

bit 4 (YCbCr 4:2:2) = 1 if Sink 
supports YCbCr 4:2:2 in addition to 

RGB. 

lower 4 bits = total number of native 
DTDs (see Section 2.2 for definition of 
"Native Video Format"). 

4 


Start reserved data block 

This section was previously reserved 
for 8 byte timing descriptors 15 but is 
currently a reserved data block. 

d -1 


End of reserved data block. 

d 


Start of 18-byte descriptors 

See Section 3.10.2 of VESA E-EDID 
Standard[9] 

c/+(18*n)-1 


End of 18-byte descriptors where n is 
the number of descriptors included 

c/+(18*n) 

0x00 

Beginning of Padding 


126 

0x00 

■ Mil 11 II 

127 


Checksum 

OxXX = This byte should be 
programmed such that a one-byte 
checksum (add all bytes together) of 
the entire 128 byte block eguals 0x00. 


Table 51 CTA Extension Version 2 (deprecated) 

7.5 CTA Extension Version 3 

Version 3 includes all of the capabilities of Versions 1 & 2, but also includes the ability to specify any of 
the CE Video Formats using “CTA Short Video Descriptors.” It provides the ability for the Sink to specify 
what types of advanced audio it supports using “CTA Short Audio Descriptors.” It also provides a way for 
the Sink to specify its speaker configuration. This information is complementary to the speaker channel 
allocation information that is sent in the Audio InfoFrame. 

If more than one CTA Extension is needed, the value of byte 3 shall be the same in all extensions. 

CTA Extension Version 3 is shown in Table 52. 


15 The 8-byte descriptors do not support the CE Video Formats defined in this standard since they are not compliant 
with VESA GTF [81], 
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Byte# 

Value 

Description 

Format 

0 

0x02 

Tag(0x02) 


1 

0x03 

Revision Number 


2 


Byte number offset d where 18-byte 
descriptors begin (typically Detailed 
Timing Descriptors) 

d = offset for the byte following the reserved data 
block. If no data is provided in the reserved data 
block, then c/=4. If d= 0, then no detailed timing 
descriptors are provided and no data is provided 
in the reserved data block collection. 

3 


Total number of Detailed Timing 
Descriptors describing Native Video 
Formats in entire E-EDID structure. 
Also, indication of underscan 
support, audio support, and support 
of YCbCr is included 

bit 7 (underscan) = 1 if Sink underscans IT 

Video Formats by default. 

bit 6 (audio) = 1 if Sink supports Basic Audio. 

bit 5 (YCbCr 4:4:4) = 1 if Sink supports YCbCr 

4:4:4 in addition to RGB. 

bit 4 (YCbCr 4:2:2) = 1 if Sink supports YCbCr 

4:2:2 in addition to RGB. 

lower 4 bits = total number of native DTDs (see 

Section 2.2 for definition of "Native Video 

Format”). 

4 


Start of data block collection 

This section is used for CTA Data Block 

Collection (see Table 53). 

d -1 


End of data block collection. 

d 


Start of 18-byte detailed timing 
descriptors 

See Section 3.10.2 of VESA E-EDID Standard 

[9] 

d+(18*n)-1 


End of 18-byte detailed timing 
descriptors where n is the number of 
descriptors included 

d+(18*n) 

0x00 

Beginning of Padding 


126 

0x00 

End of Padding 

127 


Checksum 

This byte should be programmed such that a 
one-byte checksum (add all bytes together) of 
the entire 128 byte block equals 0x00. 


Table 52 CTA Extension Version 3 

The lower 4 bits of byte 3 indicates the total number of DTDs defining Native Video Formats in the whole 
EDID (see Section 2.2 for definition of "Native Video Format").The placement of native DTDs shall be 
contiguous, starting with the first DTD in the DTD list (which starts in the base EDID block). Value zero 
means that this information is not provided (for backward compatibility with prior implementations), or that 
the display does not support reception of Native Video Format, or that the Native Video Format cannot be 
represented as a DTD. 

In most cases, the Native Video Format count equals one, but a CRT-based display may indicate support 
for two: a native progressive and a native interlaced timing. 

As with the Version 1 CTA Extension, the first detailed timing (DTD) listed in the base EDID data structure 
of the Version 3 CTA Extension is preferred. The first Short Video Descriptor (SVD), listed in the first CTA 
Extension, is also preferred. 

NOTE: Because DTDs are not able to represent some Video Formats, which can be represented 
as SVDs and might be preferred by Sinks, the first DTD in the base EDID data structure and the 
first SVD in the first CTA Extension can differ. When the first DTD and SVD do not match and the 
total number of DTDs defining Native Video Formats in the whole EDID is zero (see Table 52, 
byte 3, lower 4 bits), the first SVD shall take precedence. 

A DTV that declares it is capable of displaying Pictures formatted in either YCbCr chroma sampling 
format (i.e., 4:2:2 or 4:4:4) shall be capable of displaying Pictures encoded in either SMPTE 170M [1] 
color space or ITU-R BT.709 [7] color space. DTVs capable of displaying Pictures encoded in other color 


96 






































CTA-861-G 


spaces may declare support for these color spaces in a Colorimetry Block stored in their EDID. The 
format of the Colorimetry Data Block is defined in Section 7.5.5. 

In order to ensure YCbCr interoperability between any two YCBCR-capable devices, a Sink that supports 
either type of YCbCr Pixel Data (4:2:2 or 4:4:4) should support both types and therefore would set both 
bits 4 and 5 of byte 3. 

NOTE—The HDMI specification requires this behavior. 

A Sink that does not support YCbCr Pixel Data shall have both bits 4 and 5 clear. 

If the Sink supports any type of digital audio on this interface, then it shall also support Basic Audio and 
shall indicate this by setting the Basic Audio bit (bit 6). 

Bit 7 of byte 3 shall be set if the Sink underscans IT Video Formats by default. 

The format of the “CTA Data Block Collection” shall conform to that shown in Table 53. The order of the 
Data Blocks is not constrained. It is also possible to have more than one of a specific type of data block if 
necessary to include all of the descriptors needed to describe the Sink’s capabilities. 

These data structures may grow in the future and so the Source shall continue to parse the known 
(currently specified) fields in a data block even if the length is longer than currently specified. 
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Byte# 

Bits 5-7 

Bits 0-4 

Video Data 
Block 

1 

Video Tag 
Code 

length=total number of video bytes following this 
byte (Li) 

2 

CTA Short Video Descriptor 1 

3 

CTA Short Video Descriptor 2 



1 +Li 

CTA Short Video Descriptor Li 

Audio Data 
Block 

2 +Li 

Audio Tag 
Code 

length=total number of audio bytes following this 
byte (L2) 

3 +Li 

CTA Short Audio Descriptor 1 

4 +Li 

5 +Li 



L1+L2 

CTA Short Audio Descriptor L2/3 

1 +L1+L2 

2+L1+L2 

Speaker 
Allocation 
Data Block 

3+L1+L2 

Speaker 

Allocation 

Tag Code 

length=total number of speaker allocation bytes 
following this byte (L 3 = 3 ) 

4+L1+L2 

Speaker Allocation Data Block Payload (3 bytes) 

5+L1+L2 

6+L1+L2 

Vendor- 
Specific 
Data Block 

7+L1+L2 

Vendor- 

Specific 

Tag Code 

length=total number of Vendor-Specific bytes 
following this byte (L4) 

8+L1+L2 

IEEE OUI third two hex digits 

9+L1+L2 

IEEE OUI second two hex digits 

1 0+L1+L2 

IEEE OUI first two hex digits 


Vendor-Specific Data Block Payload (L 4-3 bytes) 

Video 
Capability 
Data Block 

8+L1+L2+L4 

Extended 

Tag Code 

length=total number of bytes in this block following 
this byte (Ls) 

9+L1+L2+L4 

Video Capabilities Ext. Tag Code = OOh 

1 0+L1+L2+L4 

Video Capabilities Data Byte 3 (see Section 7 . 5 . 6 ) 


Table 53 General Format of “CTA Data Block Collection” 


The header of a Data Block consists of one byte (Table 54), with 3 bits used for the tag code to label the 
type of data and 5 bits used to indicate the length of the block. The list of tag codes is shown in Table 55. 
The length does not include the tag. The General Tag format is shown in Table 54. The first three bits are 
a Tag Code. This Tag Code designates the format of the bytes that follow. The last five bits are a length 
field that designates the number of bytes in the data block associated with the tag. The number of bytes 
does not include the tag. In the case of a Video Data Block or an Audio Data Block, the data block 
consists of a number of Short Video Descriptors. For other data blocks, the format may be different (e.g., 
Speaker Allocation Data Block). However, the length is always the number of bytes following the tag. 



bits j 

Byte# 

l 7 

6 

5 

4 

3 

2 

1 

_ 0 _ 

1 

Tag Code 

Length of following data block payload (in bytes) [ 


Table 54 Data Block Header Byte 
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Codes 

Type of Data Block 

0 

Reserved 

1 

Audio Data Block (includes one or more Short Audio 
Descriptors) 

2 

Video Data Block (includes one or more Short Video 
Descriptors) 

3 

Vendor-Specific Data Block 

4 

Speaker Allocation Data Block 

5 

VESA Display Transfer Characteristic Data Block [991 

6 

Reserved 

7 

Use Extended Tag 


Table 55 CTA Data Block Tag Codes 


If the Tag Code is 7 (Use Extended Tag) then the second byte of the data block contains the Extended 
Tag Code, which indicates the actual type of the data block. For backwards compatibility, the Length field 
in the first byte does include the second byte, which contains the Extended Tag Code. Note that data 
blocks with Tag Codes of 1 through 6 are limited to containing 31 useful bytes whereas those with 
Extended Tag Codes are limited to 30 useful bytes. 



bits f 

Byte# 

1 7 

6 

5 

4 

3 

2 

1 

_o_ 

2 

Extended Tag Code | 


Table 56 Extended Tag Format (2 nd Byte of Data Block) 


Extended Tag 
Codes 

Type of Data Block 

0 

Video Capability Data Block 

1 

Vendor-Specific Video Data Block 

2 

VESA Display Device Data Block [100] 

3 

VESA Video Timing Block Extension 

4 

Reserved for HDMI Video Data Block 

5 

Colorimetry Data Block 

6 

HDR Static Metadata Data Block 

7 

HDR Dynamic Metadata Data Block 

8...12 

Reserved for video-related blocks 

13 

Video Format Preference Data Block 

14 

YCbCr 4:2:0 Video Data Block 

15 

YCbCr 4:2:0 Capability Map Data Block 

16 

Reserved for CTA Miscellaneous Audio Fields 

17 

Vendor-Specific Audio Data Block 

18 

Reserved for HDMI Audio Data Block 

19 

Room Configuration Data Block 

20 

Speaker Location Data Block 

21...31 

Reserved for audio-related blocks 

32 

InfoFrame Data Block (includes one or more Short InfoFrame Descriptors) 

33...255 

Reserved 


Table 57 CTA Data Block Tag Codes 


Any data block with an Extended Tag in the 0 to 15 range indicates strictly video-related characteristics of 
the display. Any repeater device that re-transmits a video stream from a Source to a Sink without any 
modification of the Video Timing or video data or video-related InfoFrame(s) shall also pass every such 
data block upstream, that is, the repeater shall copy the contents of the data block(s) from the 
downstream Sink’s EDID to the repeater’s own upstream EDID. 
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Any data block with an Extended Tag in the 16 to 31 range indicates strictly audio-related characteristics 
of the display. Any repeater device that re-transmits an audio stream from a Source to a Sink without any 
modification of the audio timing or audio data or audio-related InfoFrame(s) shall also pass every such 
data block upstream, that is, the repeater shall copy the contents of the data block(s) from the 
downstream Sink’s EDID to the repeater’s own upstream EDID. 

Repeaters shall not copy the contents of any other data block from a downstream EDID to their own 
upstream EDID unless the characteristics of the Sink indicated by that data block are known to be also 
true for the repeater device or the combination of the repeater and downstream device. This also applies 
to the original Vendor-Specific Data Block (Data Block Tag = 3); if the repeater does not recognize the 
vendor ID or does not understand the entire contents of that block, it shall not be copied into the 
repeater’s EDID. 

When a Version 3 CTA Extension is provided in the Sink’s EDID data structure, a Short Video Descriptor 
(SVD) shall be provided for each CTA Video Format supported by the Sink. SVDs shall be listed using 
one (or more) Video Data Blocks (see Section 7.5.1) and/or YCbCr 4:2:0 Video Data Blocks (see Section 
7.5.10). 

If the Sink supports YCbCr 4:2:0 sampling capability, then a YCbCr 4:2:0 Video Data Block (Y420VDB, 
see Section 7.5.10) and/or a YCbCr 4:2:0 Capability Map Data Block (Y420CMDB, see Section 7.5.11) 
shall be included in the CTA Extension. Source devices shall not transmit a Video Format in YCbCr 4:2:0 
sampling mode to a Sink device unless support for YCbCr 4:2:0 mode is indicated in a Y420VDB or 
Y420CMDB for that Video Format. 

7.5.1 Video Data Block 

A Video Data Block (VDB) lists Video Formats supported by the Sink. Each supported Video Format is 
represented by a Short Video Descriptor (SVD) containing a Video Identification Code (VIC) and, in the 
case of VICs 1 through 64, a Native Video Format indicator. 

For VICs 1 through 64, the format of the Short Video Descriptor shall conform to that shown in Table 58. 
The lower 7-bits are an index associated with the Video Format supported. The most significant bit 
declares whether the format is a Native Video Format of the display (native =1, not native = 0). Typically, 
there is a single SVD, with its native bit set. Sources should not necessarily convert Video Formats to a 
Native Video Format, but should follow recommendations for using Source Pass-through Mode and 
preferred timing (see Section 7.2.3). 



bits | 

Byte# 

7 

6 

5 

4 

3 

2 

1 

_o_ 

1 

Native 

Video Identification Code j 


Table 58 Short Video Descriptor (for codes 1 through 64) 


For VICs 65 through 127 and 193 through 255, the format of the SVD shall conform to that shown in 
Table 59. In this case, all 8-bits are an index associated with the format supported and Native Video 
Formats are communicated via other means. 



bits 1 

Byte# 

7 

6 

5 

4 

3 

2 

1 

_o_ 

1 

Video Identification Code J 


Table 59 Short Video Descriptor (for codes 65 through 127 and 193 through 255) 


The indexes are the same as those used in the AVI InfoFrame and are shown in Table 3. All DTDs and 
SVDs shall be listed in order of priority; meaning that the first is the one that the display manufacturer has 
identified as optimal. 
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The Source shall interpret SVD codes according to the following pseudo code: 

If SVD = 0 then 

Reserved 

Elseif SVD >=1 and SVD <=64 then 

7- bit VIC is defined (7-LSB’s) and NOT a native code 
Elseif SVD >=65 and SVD <=127 then 

8- bit VIC is defined (from first new set) 

Elseif SVD ==128 then 

Reserved 

Elseif SVD >=129 and SVD <=192 then 

7- bit VIC is defined (7-LSB's) and IS a native code 
Elseif SVD >=193 and SVD <=253 then 

8- bit VIC is defined (from second new set) 

Elseif SVD ==254 then 

Reserved 

Elseif SVD == 255 then 
Reserved 

End if 
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7.5.2 Audio Data Block 

If audio is supported in the Sink, as indicated by the Basic Audio support bit in the Version 3 CTA EDID 
Descriptor, then CTA short audio descriptors shall be used to declare which (if any) audio formats are 
supported in addition to Basic Audio. If only Basic Audio is supported, no Short Audio Descriptors are 
necessary. 

The Short Audio Descriptor shall conform to the formats given in Table 60 through Table 65 as a function 
of the Audio Format Code. Several types of audio may be supported, but each one shall be listed in its 
own short audio descriptor with its designated code and the associated information. The list of Audio 
Format Code values is given in Table 31 and Table 33. 

Each Short Audio Descriptor is 3-bytes long. There can be up to 31 bytes following any tag, therefore 
there may be up to 10 Short Audio Descriptors in the Audio Data Block (ADB). 

The format of the second and third bytes is determined by the Audio Format Code contained in the first 
byte as shown in Table 60 through Table 65. One format code is used for Uncompressed Audio (i.e., L- 
PCM), and the others are used for Compressed Audio (e.g., AC-3, MPEG2, DTS, etc.). For some 
compressed formats, byte 3 is further defined in other format-specific documents. 



bits ] 

Byte# 

7 

6 

5 

4 

3 

2 

1 

_9_ 

1 

F17=0 


Audio Format Code = 0001 

Max Number of channels - 1 1 

2 

F27=0 

192 kHz 

176.4 kHz 

96 kHz 

88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz 

3 

F37=0 

F36=0 

F35=0 

F34=0 

F33=0 

24 bit 

20 bit 

16 bit 


Table 60 CTA Short Audio Descriptor for Audio Format Code = 1 (L-PCM) 



bits \ 

Byte# 

7 

6 5 4 3 

2 1 0 

1 

FI 7=0 

Audio Format Code 

Max Number of channels -1 

2 

F27=0 

192 kHz | 176.4 kHz | 96 kHz | 88.2 kHz 

48 kHz | 44.1 kHz | 32 kHz 

3 

Maximum bit rate divided by 8 kHz [ 


Table 61 CTA Short Audio Descriptor for Audio Format Codes 2 to 8 



bits 

Byte# 

7 

6 

5 

4 

3 

2 

1 

0 

1 

FI 7=0 

Audio Format Code 

Max Number of channels -1 j 

2 

F27=0 

192 kHz 

176.4 kHz 

96 kHz 

88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz | 

3 

Audio Format Code dependent value. 


Table 62 CTA Short Audio Descriptor for Audio Format Codes 9 to 13 



bits | 

Byte# 

7 

6 5 4 3 

2 1 0 

1 

F17=0 

Audio Format Code=1110 

Max Number of channels -1 

2 

F27=0 

192 kHz | 176.4 kHz | 96 kHz | 88.2 kHz 

48 kHz | 44.1 kHz | 32 kHz 

3 

Reserved | Profile j 


Table 63 CTA Short Audio Descriptor for Audio Format Code 14 (WMA Pro) 


When the Audio Format Code bit-field in Data Byte 1 of a CTA Short Audio Descriptor is set to 15, it shall 
conform to the formats given in Table 64 or Table 65 as a function of the Audio Coding Extension Type 
Code. 
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The Audio Format Code Extension contained in the third byte, as shown in Table 64 and Table 65, 
determines the format of the third byte. For some compressed formats, byte 3 is further defined in other 
format-specific documents. 



bits | 

Byte# 

7 

6 5 4 3 

2 

1 

_o_ 

1 

F17=0 

Audio Format Code=1111 

Max Number of channels -1 | 

2 

F27=0 

F26=0 | F25=0 | 96 kHz | 88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz 

3 

Audio Coding Extension Type Code 

1024_TL 

960_TL 

F30=0 


Table 64 CTA Short Audio Descriptor for Audio Coding Extension Type Codes 4 to 6 


For audio format extension type code values 4, 5, 6, 8 & 10 (decimal), bits 1 and 2 of Data Byte 3 (see 
Table 64 and Table 65) are used to indicate support for different AAC audio frame lengths. If an AAC 
frame length of 960 samples is supported, bit 1 shall be set to 1. If an AAC frame length of 1024 sample 
is supported, bit 2 shall be set to 1. 



bits | 

Byte# 

7 

6 5 4 3 

2 

1 

_o_ 

1 

F17=0 

Audio Format Code=1111 

Max Number of channels -1 I 

2 

F27=0 

F26=0 | F25=0 | 96 kHz | 88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz 

3 

Audio Coding Extension Type Code 

1024_TL 

960_TL 

MPS_L 


Table 65 CTA Short Audio Descriptor for Audio Extension Type Codes 8 and 10 


MPEG Surround (MPS) data may be present in MPEG-4 AAC bit streams. When present, MPS provides 
a significant increase of audio compression efficiency. Spatial audio data can be conveyed in the AAC 
extension_payload() mechanism using extension_type EXT_SAC_DATA or as a second layer in the 
PayloadMux(), as defined by ISO/IEC 14496-3 [25]. The presence of MPS data can be signaled either 
implicitly or explicitly. With implicit signaling, the mere presence of the EXT_SAC_DATA extension 
elements in the bit stream implies that MPS data is present. With explicit signaling, the presence of MPS 
data is signaled by means of the audio object type (AOT) MPEG Surround (30) in the 
AudioSpecificConfig() data, which permits the conveyance of configuration data specific to the MPS 
decoder [25]. 

For audio format extension type code values 8 and 10 (decimal), bit 0 of Data Byte 3 (see Table 65) is 
used to indicate whether the Sink supports implicit or both implicit and explicit signaling of MPEG 
Surround data. If the bit 0 is set to 0, then the Sink supports only implicitly signaled MPEG Surround data. 
If bit 0 is set to 1, then the Sink supports both implicitly and explicitly signaled MPEG Surround data. 

It is strongly recommended that, if a Sink indicates support for core audio stream coding type (e.g., 
MPEG-4 HE AAC), then the Sink should be able to receive MPEG Surround (e.g., MPEG-4 HE AAC + 
MPEG Surround) and be able to decode the core audio stream and ignore the MPEG Surround extension 
in the bit stream. Also, it is strongly recommended that Source devices should not refuse transmission of 
an implicitly signaled MPEG Surround-encoded audio stream if the Sink device indicates support for the 
core audio stream coding type, but does not indicate support for the core audio stream in conjunction with 
MPEG Surround. 



bits 

Byte# 

7 

6 | 5 | 4 | 3 

2 

1 

0 

1 

FI 7=0 

Audio Format Code=1111 

F12=0 

F11=0 

F10=0 

2 

F27=0 

192 kHz | 176.4 kHz | 96 kHz | 88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz 

3 

Audio Coding Extension Type Code=0x0B 

Audio Format Code dependent value 


Table 66 CTA Short Audio Descriptor for Audio Extension Type Code 11 (MPEG-H 3D Audio) 
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bits 

Byte# 

7 

6 | 5 | 4 | 3 

2 

1 

0 

1 

FI 7=0 

Audio Format Code=1111 

F12=0 

F11=0 

F10=0 

2 

F27=0 

192 kHz | F25=0 | 96 kHz | F23=0 

48 kHz 

44.1 kHz 

F20=0 

3 

Audio Coding Extension Type Code=0x0C 

Audio Format Code dependent value 


Table 67 CTA Short Audio Descriptor for Audio Extension Type Code 12 (AC-4) 



bits 

Byte# 

7 

6 | 5 | 4 | 3 

2 

1 

0 

1 

MC3 

Audio Format Code=1111 

MC2 

MCI 

MCO 

2 

MC4 

192 kHz | 176.4 kHz | 96 kHz | 88.2 kHz 

48 kHz 

44.1 kHz 

32 kHz 

3 

Audio Coding Extension Type Code=0x0D 

24 bit 

20 bit 

16 bit 


Table 68 CTA Short Audio Descriptor for Audio Extension Type Code 13 (L-PCM 3D Audio) 


For Audio Coding Extension Type OxOD (L-PCM 3D Audio), bits MC4:MC0 of bytes 1 and 2 indicate Max 
Number of Channels -1. 

The Audio Format Codes used in each Short Audio Descriptor shall be as defined for CT0-CT3 in Table 
31 except that the value zero shall be reserved. The Audio Coding Extension Type Codes shall be as 
defined for CXT0-CXT4 in Table 33. 


7.5.3 Speaker Allocation Data Block 

If the Sink supports multi-channel uncompressed digital audio as indicated in the Audio Data Block, then 
the Speaker Allocation Data Block shall be included in the CTA Extension. It is recommended that the 
Sink include a valid Speaker Allocation Data Block if it supports any type of digital audio (including Basic 
Audio), but this is not required. 

The payload of the Speaker Allocation Data Block is shown in Table 69. This payload is preceded by a 
Tag Code Byte that includes a tag equal to 4 and a length of 3 (see Table 53 and Table 55). The first byte 
of the Data block payload consists of eight bits and the second byte of the Data block payload consists of 
three bits and five reserved bits. The Sink signifies that a speaker, or pair of speakers, is present by 
setting the bit associated with that speaker or pair of speakers to one. The speaker designations are the 
same as is used in the Audio InfoFrame (see Figure 6 and Table 34). In many cases, a single flag 
represents a channel pair (2 channels). Using the Speaker Allocation Data Block, these paired 
configurations cannot be represented independently. If independent representation of these channels is 
desired, then all channels must be represented with a Speaker Location Descriptor which is contained in 
a Speaker Location Data Block, (see section 7.5.16). 



bits | 

Byte# 

7 

6 

5 

4 

3 

2 

1 

0 

1 

FLW/FRW 

RLC/RRC 

FLC/FRC 

BC 

BL/BR 

FC 

LFE 

FL/FR 

2 

TpSiL/TpSi 

R 

SiL/SiR 

TpBC 

LFE2 

LS/RS 

TpFC 

TpC 

TpFL/TpFH 

3 

F37=0 

F36=0 

F35=0 

F34=0 

TpLS/Tp 

RS 

BtFL/Bt 

FR 

BtFC 

TpBL/TpBR 


Table 69 Speaker Allocation Data Block Payload 16 


7.5.4 Vendor-Specific Data Block 

The content of the Vendor-Specific Data Block is defined in Table 53. 


16 Note that some speaker names have changed from CTA-861-F and CTA-861-G. See Annex Q for details. 
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A Sink may contain one or more Vendor-Specific Data Blocks (VSDB) to indicate proprietary information 
that may be of interest to the vendor's own Sources. 

The VSDB shall contain the 3 bytes of the IEEE OUI as well as any additional payload bytes needed. 

NOTE—HDMI Sinks use one version of the VSDB to indicate HDMI-specific characteristics of the 
Sink. Additional VSDBs, such as those with the vendor's own IEEE OUI, may also be included in 
the E-EDID. 

7.5.5 Colorimetry Data Block 

The Colorimetry Data Block indicates support of specific extended colorimetry standards and gamut- 
related as yet, undefined metadata. Details regarding the contents of the Colorimetry Data Block are 
provided in Table 70, Table 71 and Table 72. 

Byte 3 is allocated for Colorimetry data. The flags for bits 0 through 4 are defined for colorimetry based 
upon the IEC 61966-2 series of standards. The flags for bits 5 through 7 are defined for colorimetry based 
upon the ITU-R BT.2020 standard. The definitions of the colorimetry flags are shown in Table 71. Setting 
a colorimetry flag to one shall indicate that the Sink is capable of displaying Pictures encoded in that 
colorimetry. 



bits f 

Byte# 

1 7 

i 6 

' 5 

I 4 

1 3 

2 

1 1 


1 

| Tag Code (0x07) 

Length of following data block (in bytes) (0x03) [ 

2 

| Extended Tag Code (0x05) [ 

3 

BT2020rgb 

BT2020ycc 

BT2020cycc 

opRGB 

opYCCeoieoi 

sYCC6oi 

XVYCC 709 

xvYCCeoi 

4 

DCI-P3 

F46=0 

F45=0 

F44=0 

MD3 

MD2 

MD1 

MD0 


Table 70 Colorimetry Data Block 


Flag 

Colorimetry 

xvYCCeoi 

Standard Definition Colorimetry based on IEC 61966-2-4 [5] 

XVYCC 709 

High Definition Colorimetry based on IEC 61966-2-4 [5] 

sYCCeoi 

Colorimetry based on IEC 61966-2-1/Amendment 1 [341 

opYCCeoi 

Colorimetry based on IEC 61966-2-5 [321, Annex A 

opRGB 

Colorimetry based on IEC 61966-2-5 [32] 

BT2020 c ycc 

Colorimetry based on ITU-R BT.2020 [39] Y’cC’bcC’rc 

BT2020ycc 

Colorimetry based on ITU-R BT.2020 [39] Y’C’bC'r 

BT2020rgb 

Colorimetry based on ITU-R BT.2020 [39] R’G’B’ 

DCI-P3 

Colorimetry based on DCI-P3 [51] [521 17 


Table 71 Data Byte 3 Colorimetry Support Flags 


Byte 4, bits 0 through 3 are listed in Table 72 and designated for future gamut-related metadata. As yet 
undefined, this metadata is carried in an interface-specific way. 


17 Note that sink shall understand two types of DCI-P3 colorimetry in [51] and [52] when this flag is set to one. 
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Flag 

Metadata 

MDO 

Future metadata profile 

MD1 

Future metadata profile 

MD2 

Future metadata profile 

MD3 

Future metadata profile 


Table 72 Data Byte 4 Colorimetry Metadata Support Flags 


7.5.6 Video Capability Data Block 

The Video Capability Data Block (VCDB) allows a display to declare default, fixed, or InfoFrame- 
controlled overscan/underscan and Quantization Range (see Table 73). Separate overscan/underscan 
handling capabilities may be declared for Preferred, IT, and CE Video Format categories. 

NOTE—The VCDB payload currently only contains a single byte in addition to the Extended Tag 
Code, while future versions may contain additional bytes. The Source should ignore such 
additional bytes (when present) and continue to parse the single byte as defined in Table 73 and 
Table 43. 



bits f 

Byte# 

7 

6 

5 

4 3 

2 1 


1 

| Tag Code (0x07) 

Length of following data block (in bytes) (0x02) | 

2 

| Extended Tag Code (0x00) I 

3 

QY 

QS 

S PT1 S PT0 S IT1 

S IT0 S CE1 

S CEO 1 


Table 73 Video Capability Data Block (VCDB) 


>- 

o 

Quantization Range 
(Applies to YCC only) 

w 

O 

Quantization Range 
Selectable 

(Applies to RGB only) 


T“ 

1- 

Q_ 

1 

W 

o 

l- 

Q_ 

1 

W 

PT 

Overscan/ 
underscan 
behavior 
(Applies to 
the 

Preferred 

Video 

Format) 


S_IT1 

o 

l- 

l 

w 

IT Overscan/ 
underscan 
behavior 
(Applies to IT 
Video 
Formats) 


1-30 S 

S_CE0 

CE Overscan/ 
underscan 
behavior 
(Applies to CE 
Video Formats) 

0 

No Data 

0 

No Data 

0 

0 

No Data 
(refer to 

S CEor 

S IT fields) 

0 

0 

IT Video 
Formats not 
supported 

0 

0 

CE Video Formats 
not supported 

1 

Selectable 
(via AVI YQ) 

1 

Selectable 
(via AVI Q) 

0 

1 

Always 

Overscanned 

0 

1 

Always 

Overscanned 

0 

1 

Always 

Overscanned 



1 

0 

Always 

Underscanne 

d 

1 

0 

Always 

Underscanned 

1 

0 

Always 

Underscanned 


1 

1 

Supports 
both over- 
and 

underscan 

1 

1 

Supports both 
over- and 
underscan 

1 

1 

Supports both 
over- and 
underscan 


Table 74 Video Capability Descriptor Data Byte 3 


Displays do not always present the entire incoming Picture to the viewer. Sometimes displays overscan 
the incoming Video Format such that pixels along the periphery of the Picture are masked (occluded). For 
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example, a display may purposely mask a portion of the Picture to hide distracting content (received from 
a Source) or the unsightly edges of a raster. In either case, what the viewer sees is either an 
underscanned or overscanned visible picture, which may either include (in the case of underscanning) the 
whole incoming Picture or (in the case of overscanning) a somewhat occluded visible Picture. 

CE application specific displays (e.g., DTVs) typically overscan all Video Formats, while IT application 
specific displays (e.g., computer displays) typically underscan all Video Formats. Multipurpose displays 
typically adapt to the incoming signal by either overscanning or underscanning depending on the type of 
Video Format received. The S_CE, S_IT, and S_PT values allow a display to formally declare its 
overscan/underscan options by CE, IT, and Preferred Video Format category (see Table 74). 

Each of the three S_xx fields indicate whether the display, for all Video Formats in that category, always 
overscan those Video Formats, always underscan those formats or support both overscanning and 
underscanning of those formats. Indications shall be accurate for all Video Format categories - so long as 
a VCDB is present in the EDID. If the display does not support the reception of one of the two main Video 
Format categories (CE and IT), then the indication for the unsupported category shall be set to 00. 

The display’s Preferred Video Format may be either a CE or an IT Video Format but may have different 
overscan/underscan behavior than the rest of the CE or IT Video Formats supported by the display. If the 
display declares a non-zero value for the S_PT (preferred timing overscan/underscan behavior) field, and 
the Source outputs that Video Format, then the S_PT declaration shall take precedence over both S_CE 
and S_IT declarations. If the S_PT field is 0 then the overscan/underscan behavior of this format is 
indicated by either the S_CE or S_IT fields, depending on whether the Preferred Video Format is a CE or 
IT Video Format. 

If the display declares that it can support both overscan and underscan for a Video Format category and 
the Source outputs that type, then the display shall either automatically overscan or underscan (in 
response to the AVI InfoFrame S field) or provide user options of selecting an overscan or an underscan 
mode. If operating in an automatic mode, the display shall overscan the incoming Picture if it receives AVI 
S=1 and it shall underscan if it receives AVI S=2. The Source shall always set the AVI S field correctly if 
that information is known by the Source. If the display receives no AVI or AVI S=0, then the display 
should overscan CE Video Formats and underscan IT Video Formats by default but may provide a user- 
selectable alternative behavior. 

If the display does not provide a VCDB then the Source should assume that CE Video Formats are 
overscanned by the display and that IT Video Format behavior is indicated by CTA Extension byte 3 bit 7 
(underscan). If underscan=1 then the Source should assume that IT Video Formats are underscanned 
and if underscan=0, that IT Video Formats are overscanned. 

If the Source outputs a Video Format that can be underscanned by the display, then the Source may 
safely place essential content at the very edge of the signaled Picture and the display shall ensure that 
the entire signaled Picture is visible. 

When outputting a Video Format that is always overscanned by the display, IT Sources (which normally 
render interactive menus and window controls along the periphery of the transmitted Picture) should 
confine essential content to a smaller area of the signaled Picture - to ensure the viewer operability. 
Media-centric Sources, on the other hand, which fill the signaled Picture with (decompressed) broadcast 
or prerecorded content - precomposed for an overscanned display, should simply pass-through such 
content without further processing (see Source Pass-through Mode). 

The exact dimensions of the overscanned visible picture may vary and are not specified in CTA-861. 

For RGB colorimetry, CTA-861 supports both limited (16*2 A (N-8) to 235*2 A (N-8)) and full (0 to (2 A N)-1) 
range data when receiving video with RGB color space. By default, RGB Pixel Data values should be 
assumed to have a Limited Range when receiving a CE Video Format and a Full Range when receiving 
an IT format (see Section 5.1). The QS (AVI Q support) bit of byte 3 allows a display to declare that it 
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supports the reception of either type of Quantization Range for any Video Format, under the direction of 
InfoFrame Q data (see Section 6.4 for information concerning bits Q1 and QO). This allows a Source to 
override the default Quantization Range for any Video Format. 

If the Sink declares a selectable RGB Quantization Range (QS=1) then it shall expect Limited Range 
pixel values if it receives Q=1 and it shall expect Full Range pixel values if it receives Q=2 (see Section 
6.4). For other values of Q, the Sink shall expect pixel values with the default range for the transmitted 
Video Format. 

When received content encoded in sYCCeoi (IEC 61966-2-1/Amendment 1 [34]), opYCCeoi, andopRGB 
(IEC 61966-2-5 [32]) colorimetry, CTA-861 supports both limited (16*2 A (N-8) to 235*2 A (N-8)) and full (0 to 
(2 A N)-1) Quantization Ranges. By default, sYCCeoi and opYCCeoi YCC Pixel Data values should be 
assumed to have a Limited Range when receiving a CE Video Format and a Full Range when receiving 
an IT format. The QY (AVI YQ support) bit of byte 3 allows a display to declare that it supports the 
reception of either type of Quantization Range for any Video Format, under the direction of AVI InfoFrame 
YQ data (see Section 6.4 for information concerning bits YQ1 and YQO). This allows a Source to override 
the default Quantization Range for any Video Format. 

If the Sink declares a selectable YCC Quantization Range (QY=1), then it shall expect Limited Range 
pixel values if it receives AVI YQ=0 and it shall expect Full Range pixel values if it receives AVI YQ=1 
(see Section 6.4). For other values of YQ, the Sink shall expect pixel values with the default range for the 
transmitted Video Format. 


7.5.7 Vendor-Specific Video Data Block 

The Vendor-Specific Video Data Block (VSVDB) allows a display to declare up to 27-bytes of vendor- 
defined video capabilities-related data (see Table 75). A Sink may contain one or more VSVDBs to 
indicate proprietary information that may be of interest to the vendor's own Sources. The VSVDB shall 
contain the 3 bytes of the vendor's IEEE OUI as well as any additional payload bytes needed. 



bits { 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code (0x07) 

Length (L) = number of bytes following this byte 

2 

Extended Tag Code (0x01) 

3 

IEEE OUI third two hex digits 

4 

IEEE OUI second two hex digits 

5 

IEEE OUI first two hex digits 

6 

through 

L+1 

Vendor-Specific Video Data Block Payload (L-4 bytes) 


Table 75 Vendor-Specific Video Data Block (VSVDB) 
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7.5.8 Vendor-Specific Audio Data Block 

The Vendor-Specific Audio Data Block (VSADB) allows a display to declare up to 27-bytes of vendor- 
defined audio capabilities-related data (see Table 76). A Sink may contain one or more VSADBs to 
indicate proprietary information that may be of interest to the vendor's own Sources. The VSADB shall 
contain the 3 bytes of the vendor's IEEE OUI as well as any additional payload bytes needed. 



bits | 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code (0x07) 

Length (L) = number of bytes following this byte 

2 

Extended Tag Code (0x11) 

3 

IEEE OUI third two hex digits 

4 

IEEE OUI second two hex digits 

5 

IEEE OUI first two hex digits 

6 

through 

L+1 

Vendor-Specific Audio Data Block Payload (L-4 bytes) 


Table 76 Vendor-Specific Audio Data Block (VSADB) 


7.5.9 InfoFrame Data Block 

An InfoFrame Data Block (IFDB) may be used to declare the number of additional Vendor-Specific 
InfoFrame (VSIFs) that can be received simultaneously, and optionally, support for particular InfoFrames 
and their relative priority (see Table 77 and example in Annex A.2.20). 



bits I 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code (0x07) 

Length (L a ) = # of bytes following this byte 

2 

Extended Tag Code (0x20) 

3 

through 

Lb+4 

InfoFrame Processing Descriptor 


(optional) Short InfoFrame Descriptor(s) 

(optional) Short Vendor-specific InfoFrame Descriptor(s) 


Table 77 InfoFrame Data Block 


The IFDB shall begin with a Data Block Header Byte (see Table 54) with Tag Code 0x07 and Length 
equal to the total number of bytes comprising the IFDB minus one. The Data Block Header Byte shall be 
immediately followed by an InfoFrame Data Block Extension Tag with code 0x20, which identifies the 
Data Block as being an IFDB. 

An InfoFrame Processing Descriptor shall immediately follow the InfoFrame Data Block Extension Tag. 

This InfoFrame Processing Descriptor shall begin with an InfoFrame Processing Descriptor Header as 
shown in Table 78. 



bits | 

Byte# 

7 1 6 | 5 

4 

3 

2 

1 

0 

1 

Length (Lb) = # of bytes 
following the next byte 

F14=0 

F13=0 

F12=0 

F11=0 

F10=0 

2 

Number of additional VSIFs that can be received simultaneously. I 


Table 78 InfoFrame Processing Descriptor Header 
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The Payload Length field of the InfoFrame Processing Descriptor Header indicates the number of 
extension bytes (if any), in the InfoFrame Processing Descriptor, that follow Byte 2 of its Header. The 
InfoFrame Processing Descriptor shall have a Payload Length of zero bytes. 

NOTE: Future revisions of CTA-861 may provide extended InfoFrame Processing Descriptor 
payload by setting the Payload Length field to a non-zero value. Therefore, Source devices shall 
use the Payload Length field of the InfoFrame Processing Descriptor Header when locating the 
beginning of other structures following the InfoFrame Processing Descriptor. 

Byte 2 of the InfoFrame Processing Descriptor Header shall be set equal to the number of additional 
VSIFs that can be received in addition to the first. If the Sink is only capable of receiving a single VSIF, 
then Byte 2 shall be set to zero. 

A list of declared InfoFrames may follow the InfoFrame Processing Descriptor. This list may be 
incomplete. When used to declare supported InfoFrames, declared InfoFrame types shall be listed using 
Short InfoFrame Descriptors (SIDs). The format of SIDs shall conform to one of two different structures - 
depending on the InfoFrame Type Code given in bits 0 through 4 of Byte 1. Vendor-Specific InfoFrames 
(InfoFrame type code 0x01) shall be declared using the format shown in Table 80, while all other 
InfoFrames types shall be declared using the format shown in Table 79. The InfoFrame type codes shall 
be the same as those listed in Table 5. Like the InfoFrame Processing Descriptor, SIDs shall have a 
Payload Length of zero bytes unless otherwise specified. The Payload Length of a Short Vendor-Specific 
InfoFrame Descriptor (shown in Table 80) refers to the number of additional bytes following the required 
3-byte OUI and shall be set to zero unless the vendor specifies additional payload bytes beyond the 24- 
bit IEEE Registration Identifier bytes. The Payload Length of a Short InfoFrame Descriptor (shown in 
Table 79) refers to the number of additional bytes following Byte 1 and shall be set to zero. 

NOTE: Future revisions of CTA-861 may increase the length of the InfoFrame Descriptor payload 
by setting the Payload Length field to a non-zero value. Source devices shall use the Payload 
Length fields of both Short Vendor-Specific and Short InfoFrame Descriptors when locating the 
beginning of other structures following the Short InfoFrame Descriptors. 



bits g 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Payload Length (bytes) 

InfoFrame Type Code (any except codes 0x00 and 
0 x01) 


Table 79 Short InfoFrame Descriptor Header 



bits | 

Byte# 

7 | 6 | 5 

4 | 3 | 2 | 1 | 0 

i 1 

Payload Length (bytes) 

InfoFrame Type Code = 0x01 

2 

IEEE OUI third two hex digits 

3 

IEEE OUI second two hex digits 

4 

IEEE OUI first two hex digits 


Table 80 Short Vendor-Specific InfoFrame Descriptor Header 


Declared InfoFrame types shall be listed in order of priority; meaning that the first is the one that the 
display manufacturer has identified as most desirable. Sources may use this information as a basis for 
selecting which InfoFrames to send (e.g., in cases where the Source may not be capable of delivering all 
defined or supported InfoFrame types). 
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7.5.10 YCbCr 4:2:0 Video Data Block 

A YCbCr 4:2:0 Video Data Block (Y420VDB) lists Video Formats, supported by the Sink, that only allow 
YCbCr 4:2:0 sampling mode (i.e., do not support RGB, YCbCr 4:4:4, or YCbCr 4:2:2 sampling modes). 
Video formats that support RGB, YCbCr 4:4:4, or YCbCr 4:2:2 sampling modes, in addition to YCbCr 
4:2:0 sampling mode, shall be listed in a regular Video Data Block (see Section 7.5.1) and marked as 
supporting YCbCr 4:2:0 sampling mode using a YCbCr 4:2:0 Capability Map Data Block (see Section 
7.5.11). 

The structure of the Y420VDB is shown in Table 81. 



bits | 

Byte# 

| 7 | 6 | 5 

4 3 2 1 0 1 

1 


Length (L) = number of bytes following this byte 

2 

Extended Tag Code (OxOE) 

3 

through 

L+1 

YCbCr 4:2:0-only SVDs (L-1 bytes) 


Table 81 YC B C R 4:2:0 Video Data Block 


Data bytes 3 through L+1 list SVDs in the same manner (including preference) as described in Section 
7.5.1 for the regular Video Data Block. 

With respect to Video Format preference, Y420VDB SVDs shall be considered separate from those of 
regular Video Data Blocks (see Section 7.5.1). By default, Y420VDB SVDs, when present in the EDID, 
shall be less preferred than all regular Video Data Block SVDs. This default ordering can be modified 
using a Video Format Preference Data Block (see Section 7.5.12). 
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7.5.11 YCbCr 4:2:0 Capability Map Data Block 

A YCbCr 4:2:0 Capability Map Data Block (Y420CMDB) indicates exactly which SVDs, listed in one or 
more regular Video Data Blocks (see Section 7.5.1), also support YCbCr 4:2:0 sampling mode - in 
addition to other modes such as RGB, YCbCr 4:4:4, and/or YCbCr 4:2:2. The Y420CMDB does not 
indicate which RGB, YCbCr4:4:4, and/or YCbCr 4:2:2 modes are supported. 

The structure of the Y420CMDB is shown in Table 82. 



bits I 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code (0x07) 

Length (L) = number of bytes following this byte 

2 

Extended Tag Code (OxOF) 

3 

through 

L+1 

YCbCr 4:2:0 Capability Bit Map (L-1 bytes) 


Table 82 YCbCr 4:2:0 Capability Map Data Block 


Data bytes 3 through L+1 contain a bit map indicating which Video Formats, relative to the set of SVDs 
listed in the regular Video Data Block(s) (see Section 7.5.1) of the EDID, support YCbCr 4:2:0 capability. 

Bit 0 of data byte 3 is associated with the first sequential SVD listed in the regular Video Data Block(s) 
(see Section 7.5.1) of the EDID, bit 1 the second SVD, bit 2 the third, and so on. If any SVD beyond the 
first eight SVDs supports YCbCr 4:2:0 capability, then additional byte(s) shall be provided, with bit 
ordering the same as byte 3 (e.g., with more than eight SVDs, bit 0 of byte 4 would indicate the YCbCr 
capability associated with the ninth sequential SVD in the set of SVDs listed in the EDID). To save space, 
not all SVDs in the EDID need be marked relative to YCbCr 4:2:0 capability (i.e., bytes that would be filled 
with all zero-bits and that are not followed by non-zero bytes do not need to be included). 

For SVDs that do not support YCbCr 4:2:0, the corresponding bit in the bit map of the Y420CMDB shall 
be set to 0. For SVDs that do support YCbCr 4:2:0, the corresponding bit in the bit map of the 
Y420CMDB shall be set to T. 

When the Length field is set to L==1, the Y420CMDB does not include a YCbCr 4:2:0 Capability Bit Map 
and all the SVDs in the regular Video Data Block(s) (see Section 7.5.1) support YCbCr 4:2:0 sampling 
mode. 
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7.5.12 Video Format Preference Data Block 

A Video Format Preference Data Block (VFPDB) indicates the order of preference for (selected) Video 
Formats listed as DTDs and/or SVDs throughout the entire EDID. When present, the VFPDB shall take 
precedence over preferred indications defined elsewhere in CTA-861-F. One particular application is a 
Sink that prefers a Video Format that is not listed as an SVD in a Video Data Block (see Section 7.5.1), 
but instead listed in a YCBCR 4:2:0 Video Data Block (see Section 7.5.10). 

The structure of the VFPDB is shown in Table 83. 



bits I 

Byte# 

1 7 | 6 | 5 

4 3 2 1 0 

1 


Length (L) = number of bytes following this byte 

2 

Extended Tag Code (OxOD) 

3 

Short Video Reference 1 

4 

Short Video Reference 2 

5 

Short Video Reference 3 



i L+1 

Short Video Reference N | 


Table 83 Video Format Preference Data Block 


Short Video Reference 1 refers to the most-preferred Video Format, while higher numbered SVRs (2, 3, 
through N) refer to Video Formats in order of decreasing preference. All Video Formats referred to in the 
VFPDB are preferred over Video Formats for which preference expressed elsewhere in the EDID. 
However, for Video Formats not referred to in the VFPDB, preferences expressed elsewhere shall be 
used. 

Short Video References (SVRs) refer to Video Formats via VICs and/or DTD indices. 

The Source shall interpret SVR codes according to the following pseudo code: 

If SVR = 0 then 

Reserved 

Elseif SVR >=1 and SVR <=127 then 
Interpret as a VIC 
Elseif SVR =128 then 
Reserved 

Elseif SVR >=129 and SVR <=144 then 

Interpret as the K th DTD in the EDID, where K = SVR - 128 (for K=1 to 16) 

Elseif SVR >=145 and SVR <=192 then 
Reserved 

Elseif SVR >=193 and SVR <=253 then 
Interpret as a VIC 

Elseif SVR >=254 and SVR <=255 then 
Reserved 

End if 
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7.5.13 HDR Static Metadata Data Block 

The HDR Data Block indicates the HDR capabilities of the Sink and is defined below: 



bits | 

Byte# 

7 

6 

5 

4 

3 

2 

1 

_0_ 

1 

j Tag Code (0x07) 

Length of following data block = n bytes j 

2 

| Extended Tag Code (0x06) j 

3 

F37=0 

F36=0 

ET_5 

ET_4 

ET 3 

ET 2 

ET 1 

ET 0 

4 

SM_7 

SM_6 

SM_5 

SM_4 

SM_3 

SM_2 

SM 1 

SM_0 

5 

Desired Content Max Luminance data (8 bits) 

6 

Desired Content Max Frame-average Luminance data (8 bits) 

7 

Desired Content Min Luminance data (8 bits) 


Table 84 HDR Static Metadata Data Block 

Byte 1 indicates the length of the following data in the Data Block. CTA-861 defines a structure up to and 
including Byte 7. Future versions may have a different number of bytes in the Data Block: Source 
implementations shall parse this Data Block according to the length specified in Byte 1. 

Byte 3, bits 0 to 5, identify the Electro-Optical Transfer Functions supported by the Sink: 


ET _n 

Supported EOTF 

ET 0 

Traditional gamma - SDR Luminance Range 

ET 1 

Traditional gamma - HDR Luminance Range 

ET 2 

SMPTE ST 2084 [40] 

ET 3 

Hybrid Log-Gamma (HLG) based on 
Recommendation ITU-R BT.2100-0 [50] 

ET 4 to ET 5 

Reserved for future use (0) 


Table 85 Supported Electro-Optical Transfer Function 


When ET_0 is set to T, the Sink indicates support for the Traditional Gamma - SDR Luminance Range 
as described in section 6.9 Dynamic Range and Mastering InfoFrame. 

When ET_1 is set to T, the Sink indicates support for the Traditional Gamma - HDR Luminance Range 
as described in section 6.9 Dynamic Range and Mastering InfoFrame. This is intended to support 
Sources without SMPTE ST 2084 [40] hardware capability. 

When ET_2 is set to T, the Sink indicates support for the EOTF defined in SMPTE ST 2084 [40]. 

When ET_3 is set to T, the Sink indicates support for the Hybrid Log-Gamma (HLG) EOTF defined in 
Recommendation ITU-R BT.2100-0 [50]. 

ET_4 to ET_5 shall be set to ‘O’. Future Specifications may define other EOTFs. 

Byte 4 indicates which Static Metadata Descriptors are supported. 


SM_n 

Supported Static Metadata Descriptor 

SM_0 

Static Metadata Type 1 

SM 1 to SM 7 

Reserved for future use (0) 


Table 86 Supported Static Metadata Descriptor 


When SM_0 is set to T, the Sink indicates support for Static Metadata Type 1 (see section 6.9.1). 
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The length of the data block, n, in Byte 1 indicates which of the Bytes 5 to 7 are present. Bytes 5 to 7 are 
optional to declare. When n = 3, Bytes 5 to 7 are not present. When n = 4, Byte 5 is present; when n = 5, 
Bytes 5 and 6 are present; and when n = 6, Bytes 5 to 7 are present. When n > 3, each of Bytes 5 to 7 
which are indicated to be present in the HDR Static Metadata Data Block may be set to zero. This value 
indicates that the data for the relevant Desired Max Content Luminance, Desired Content Max Frame- 
average Luminance or Desired Content Min Luminance is not indicated. 

Byte 5 indicates the Desired Content Max Luminance Data. This is the content’s absolute peak luminance 
(in cd/m 2 ) (likely only in a small area of the screen) that the display prefers for optimal content rendering. 
Byte 5 contains an 8-bit value representing a perceptually coded value of the Desired Content Maximum 
Luminance. 

Byte 6 indicates the Desired Content Max Frame-average Luminance. This is the content’s max frame- 
average luminance (in cd/m 2 ) that the display prefers for optimal content rendering. Byte 6 contains an 8- 
bit value representing a perceptually coded value of the Desired Content Max Frame-average Luminance. 

The luminance values represented by Bytes 5 and 6 are calculated from: 


Luminance value= 50 ■ 2< cv/32 > 


where CV (code value) is the decimal equivalent of the value of the byte. 

Byte 7 indicates the Desired Content Min Luminance. This is the minimum value of the content (in cd/m 2 ) 
that the display prefers for optimal content rendering. Byte 7 contains an 8-bit value representing a 
perceptually coded value of the Desired Content Min Luminance and is calculated from: 

Desired Content Min Luminance = Desired Content Max Luminance (CV/255) 2 / 100 

where CV (code value) is the decimal equivalent of the value of Byte 7. 


7.5.14 HDR Dynamic Metadata Data Block 

The HDR Dynamic Metadata Data Block is shown in Table 87 below. 



bits 

Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code (0x07) 

Length of following data block (in bytes) 

2 

Extended Tag Code (0x07) 

3 

Length of following data for supported HDR Dynamic Metadata Type n 

4 

Supported HDR Dynamic Metadata Type n LSB 

5 

Supported HDR Dynamic Metadata Type n MSB 

6 

Support Flags for HDR Dynamic Metadata Type n 


Optional Fields for HDR Dynamic Metadata Type n 




Length of following data for supported HDR Dynamic Metadata Type m 


Supported HDR Dynamic Metadata Type m LSB 


Supported HDR Dynamic Metadata Type m MSB 


Support Flags for HDR Dynamic Metadata Type m 


Optional Fields for HDR Dynamic Metadata Type m 




Table 87 HDR Dynamic Metadata Data Block 


The Supported HDR Dynamic Metadata Type indicates support for a specific type of HDR Dynamic 
Metadata, using the values of the Extended InfoFrame Type Codes as indicated in Table 47. Note that 
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there is no requirement for the order of Supported HDR Dynamic Metadata Types in the Data Block, so 
Sources shall parse all bytes of the Data Block to establish a Sink’s support. 

When Supported HDR Dynamic Metadata Type has a value of 0x0001, Support Flags is as shown in 
Table 88: 


I bits 1 

m 

! 6 

5 

1 4 

! 3 

i 2 

1 

1_o_1 

Reserved 

type_1 _h d r_metad ata_ve rs io n 


Table 88 Support Flags for Supported HDR Dynamic Metadata Type 0x0001 


In this case, a Sink supporting the HDR Dynamic Metadata Data Block shall indicate which 
type_1_hdr_metadata_version it supports. 

When Supported HDR Dynamic Metadata Type has a value of 0x0002, Support Flags is as shown in 
Table 89: 


9 bits | 


6 

5 

! 4 

i 3 

2 

1 

1 _o_1 

Reserved 

ts_103_433_spec_version 


Table 89 Support Flags for Supported HDR Dynamic Metadata Type 0x0002 


In this case, a Sink supporting the HDR Dynamic Metadata Data Block shall indicate which 
ts_103_433_spec_version it supports. 

When Supported HDR Dynamic Metadata Type has a value of 0x0003, no Support Flags or Optional 
Fields are currently defined. In this case the HDR Dynamic Metadata Data Block Byte 3, specifying the 
Length of following data for supported HDR Dynamic Metadata Type 3, shall be set to 0x02. 

When Supported HDR Dynamic Metadata Type has a value of 0x0004, Support Flags is as shown in 
Table 90: 


1 bits | 


! 6 

5 

! 4 

i 3 

1 2 

1 

1 _o_1 

Reserved 

type_4_h d r_metad ata_ve rs io n 


Table 90 Support Flags for Supported HDR Dynamic Metadata Type 0x0004 


In this case, a Sink supporting the HDR Dynamic Metadata Data Block shall indicate which 
type_4_hdr_metadata_version it supports 

Each Supported HDR Dynamic Metadata Type may also indicate support for other optional fields relevant 
to that Type. No such Optional Fields are included in this specification. Therefore, the length of following 
data for each Supported HDR Dynamic Metadata Type is 3 (indicating that no Optional Fields are 
present). 

The total amount of data required to indicate a Sink’s support may be larger than can be accommodated 
in a single HDR Dynamic Metadata Data Block. In this case, multiple HDR Dynamic Metadata Data 
Blocks may be used to carry all such information and Sources shall parse all instances of these Data 
Blocks. Each HDR Dynamic Metadata Data Block shall contain all the data needed for any particular 
HDR Dynamic Metadata Type and shall not split that data over more than one HDR Dynamic Metadata 
Data Blocks. 
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7.5.15 Room Configuration Data Block 

The Room Configuration and Speaker Location Data Blocks are capable of fully describing the playback 
environment using the room coordinate system defined in 7.5.16.1 

Information here can be in excess of, or in conflict with, the speaker definitions in the Speaker Allocation 
Data Block. If the source is capable of using the Room Configuration Data Block, then it shall ignore the 
Speaker Allocation Data Block (if present). 

The Room Configuration Data Block is shown in Table 91 below. 


Byte# 

7 

6 

5 

4 

3 

2 

1 

0 

1 

Tag Code = 7 

Length of following block payload (bytes) j 

2 

Extended Tag Code (0x13) | 

3 

Display 

Speaker 

SLD 

Speaker Count | 

SPM1 

FLW/FRW 

RLC/RRC 

FLC/FRC 

BC 

BL/BR 

FC 

LFE1 

FL/FR 

SPM2 

TpSiL/TpSiR 

SiL/SiR 

TpBC 

LFE2 

LS/RS 

TpFC 

TpC 

TpFL/TpFR 

SPM3 

F67=0 

F66=0 

F65=0 

F64=0 

TpLS/TpRS 

BtFL/BtFR 

BtFC 

TpBL/TpBR 

MAXI 

Xmax 

MAX2 

Ymax 

MAX3 

Zmax 

DISP1 

DisplayX 

DISP2 

DisplayY 

DISP3 

DisplayZ 


Table 91 Room Configuration Data Block 


Speaker - If Speaker = 1 then Speaker Count is valid. If Speaker = 0, then Speaker Count is 

undefined. A valid Speaker Count is optional for configurations described only with a SPM flag, and 
mandatory for configurations described using at least one Speaker Location Descriptor. 

SPM1 - SPM3 - Speaker Presence Mask. Channel-name mnemonics used in this register are found in 
Table 34 and the SPM 1-SPM3 fields are otherwise identical to the Speaker Allocation Mask defined in 
section 7.5.3. The flags in this 3 byte register indicate the presence of speakers by name. If a flag is set to 
one then the indicated position is present, and if the flag is set to zero then the respective position is not 
present. 

For L/R paired positions, the corresponding flag in the SPM is set to 1 only if both speakers exist. 
Speakers that are a part of an incomplete pairing can only be represented using the Speaker Location 
Descriptor. 

SLD - If SLD = 1, then Speaker Location Descriptors are available, and Xmax, Ymax and Zmax are set 
to meaningful values. If SLD = 0, then Speaker Location Descriptors are not available and only the SPM 
register is used to describe the speaker layout. Xmax, Ymax and Zmax shall be ignored. 

Speaker Count - This is a 5 bit unsigned integer value equal to the total number of L-PCM channels - 1. 
Speaker Count is required if the Speaker Location Descriptor is used. 

Note that a discrepancy between SPM1 - SPM3 and Speaker Count is possible for systems using spatial 
coordinates. 

Xmax - An 8-bit integer equal to the absolute value of the maximum distance along the X axis from the 
Primary Listening Position (PLP) to the furthest speaker in decimeters (dm). This parameter is required in 
order to use spatial coordinates for advanced room configurations. 
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Ymax - An 8-bit integer equal to the absolute value of the maximum distance along the Y axis from the 
PLP to the furthest speaker in dm. This parameter is required in order to use spatial coordinates for 
advanced room configurations. 

Zmax - An 8-bit integer equal to the absolute value of the maximum distance along the Z axis from the 
PLP to the furthest speaker in dm. This parameter is required in order to use spatial coordinates for 
advanced room configurations. 

Display - If Display = 1, then the display values in bytes DISP1 through DISP3 contain valid data. 

Display shall be 0 if SLD is 0. 

DisplayX - A Coordinate Value normalized to Xmax equal to distance between the PLP and the center of 
the display along the x-axis. 

DisplayY - A Coordinate Value normalized to Ymax equal to distance between the PLP and the center of 
the display along the y-axis. 

DisplayZ - A Coordinate Value normalized to Zmax equal to distance between the PLP and the center of 
the display along the z-axis. 

Note: Only the location of the display is expressed here. The display’s width and height are 
available from the 'Max Horizontal Image Size’ and ‘Max Vertical Image Size’ fields that are 
assigned on address 0x15 and 0x16 in the VESA E-EDID specification. HDMI provides additional 
means to define the value range of the VESA Image Size parameter, and that feature should be 
set accordingly. 

7.5.16 Speaker Location Data Block 

The Speaker Location Data Block is described in Table 92. Multiple Speaker Location Data Blocks may 
be required to contain all of the Speaker Location Descriptors need to describe a system. 


Byte# 

7 6 5 

4 3 2 1 0 

1 

Tag Code = 7 

Length of following block payload (bytes) 

2 

Extended Tag Code (0x14) 

3 through 
Length + 1 

Speaker Location Descriptors 


Table 92 Speaker Location Data Block 


The Speaker Location Descriptor, shown in Table 93, is a data structure for providing additional 
information about a particular channel. The use of the Speaker Location Descriptor shall only be used 
when the corresponding parameters SLD and Speaker Count have been set in the Room Configuration 
Data Block. It describes one PCM channel with a Channel Index, a Speaker ID, and/or speaker 
coordinates. It occupies 2 or 5 bytes, depending on the flags in the first byte. 


Byte \ Bit# 

7 

6 

5 

4 3 2 1 0 

Channel 

F17=0 

COORD 

Active 

Channel Index (0 to 31) 

ID 

F27=0 

F26=0 

F35=0 

Speaker ID (0 to 31) (from Table 34) 

COORD1 

X 

COORD2 

Y 

COORD3 

Z 


Table 93 Speaker Location Descriptor 


Channel Index: Index of the audio channel where the audio for the described speaker is to be transmitted. 
A source shall order the channels following these implementation guidelines: 
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1. The channel indices (from 0 to 31) will indicate the ordering of the L-PCM feeds being delivered. 

2. Pairs should be kept together, with the “R" on the second channel of a channel pair. 

3. Duplicate speaker IDs are in consecutive channel numbers, with no special regard to pairing. 

As a consequence of these guidelines, a Source delivering OBA will have the information necessary to 
render to all available speaker feeds. 

In OBA, where both Source and Sink support speaker locations based on room coordinates, there exists 
the possibility that some channels will share a name - e.g. there may be 2 ‘center’ channels, so default 
channel ordering is not possible. Consequently the Audio InfoFrame Data Byte 4 shall be set to OxFF 
(see Table 35). 

Active - If Set to 1, then the channel shall be rendered on a speaker by the Sink. If set to 0, the 
respective channel is unused. The total number of Active flags set to 1 shall match the Speaker Count in 
the Room Configuration Descriptor Data Block. 

COORD - If Set to 1, then the three bytes COORD1, COORD2 and COORD3 shall be present and the X, 

Y and Z fields shall contain valid data. If set to 0, the COORD1, COORD2, and COORD3 bytes shall not 
be present in the Speaker Location Descriptor. 

Speaker ID - Shall identify the type of speaker being described (see Table 34) 

X - The normalized position of this speaker on the X axis relative to the PLP represented by a Coordinate 
Value. 

Y - The normalized position of this speaker on the Y axis relative to the PLP represented by a Coordinate 
Value. 

Z - The normalized position of this speaker on the Z axis relative to the PLP represented by a Coordinate 
Value. 


7.5.16.1 Room Coordinate System 

The CTA Room Coordinate System describes the spatial location of components in a viewing and/or 
listening environment, such as the speakers and the display. These coordinates can then be translated to 
suit the needs of the various OBA rendering algorithms used to create a customized listening experience. 

The origin of the Room Coordinate System is defined to be the most optimal seated listening position in 
the room. This is denoted as the Primary Listening Position (PLP). 

The Room Coordinate System shall be based on a rectangular box that contains all of the components of 
interest centered on the PLP. 

Xmax, Ymax and Zmax shall define the extremities of this box expressed as unsigned integer values in 
decimeters 18(dm). Note that this will describe rooms as large as 51 meters on each axis. 


The X axis is positive to the right of the PLP, from the perspective of the listener. 
The Y-axis is positive from the PLP going forward toward the Display. 


18 1dm = 10cm = 100mm = approximately 4 inches 
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The Z-axis is positive from the PLP going Up. 

The coordinate values along each axis shall be normalized by the maximum absolute excursion on that 
axis. 

The procedure for characterizing a room shall be as follows: 

The point of measurement for the display position shall be the center of the viewing area on the display 
surface. 

The point of measurement for each speaker is at the acoustic center on the inward facing surface for 
direct speakers, and the acoustic center of the reflected or virtual sound field for reflected and virtualized 
speakers. 

Normalized parameters are represented in 1.6 signed two’s complement format, as in Table 94 below: 


Bit 

7 

6 

5 

4 

3 

2 

1 



S 

1 

F 

F 

F 

F 

F 

F 


Table 94 Coordinate Value Format 


S = sign bit (MSB). If the sign bit (S) equals zero, then the Coordinate Value is positive. If the sign bit (S) 
equals one, then the Coordinate Value is negative. 

I = integer portion. 

F = fractional portion. Since there are 6 fractional bits, the scaling factor is 1/2 6 = 1/64. For example, a 
value of11111111b = -1/64. 

The Coordinate Value Format represents values from -2 to +1.984375 in steps of .015625 or (1/64). 

For example, if Xmax = 30 dm, (3 m), then the unit resolution of the axis is about 5 cm. 
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Annex A Baseline Example EDID and Detailed Timing Descriptors (Informative) 

This Annex provides a baseline example EDID for features and functions contained in CTA-861. The 
example EDID presented here is not meant to illustrate all conceivable combinations for data block types 
or lengths. For example, Annex D provides another example EDID for use with the HDMI implementation 
of CTA-861. 

Annex A addresses issues related to the VESA Extended Display Identification Data (EDID) tables 
utilized within CTA-861. 

Annex A provides examples and guidance to manufacturers that utilize CTA-861; however included in this 
Annex are several normative requirements identified by the "shall" verb. Specifically, this guidance is for 
the implementation of EDID tables. Primarily, the motivation is to help insure interoperability between 
various Sources and Sinks. Annex A should in no way prohibit consumer device manufacturers from 
including additional features, and Annex A should not be interpreted as stipulating any form of upper limit 
to EDID features. 

A.1 Background 

CTA-861 follows requirements in the VESA Enhanced Extended Display Identification Data Standard (E- 
EDID). EDID tables exist within the Sink and are used to declare its capabilities to Sources. The Source 
uses these declared capabilities to determine the appropriate signal parameters to send across the 
interface for consumption by the Sink. 

Possibly, there are varied and inconsistent ways to create EDID tables and therefore, a common 
methodology is desirable to help insure interoperability between various Sink and Sources. The purpose 
of Annex A is to provide a consistent and understandable guideline for creating EDID tables that reside 
within consumer electronics products. Consequently, Annex A does not address implementations that 
utilize repeaters. 

A.2 EDID Tables 

CTA-861 requires use of the VESA EDID version 1, revision 3 data structure. Previous versions of EDID 
are not supported and such use is deprecated. EDID Version 1, Revision 3 requires use of certain 
features for Computer Displays. Despite these requirements, some features are not applicable to certain 
display technologies and applications. For example, the Monitor Range Limits descriptor and support of 
the Generalized Timing Formula apply to CRT based multi-scan systems and not flat panel or most 
consumer electronics equipment. For consumer electronics devices (CE devices) the application is limited 
to a simple declaration of the Sink’s capabilities and attributes. This section provides an outline describing 
the various blocks that reside with the EDID structure. 

A.2.1 EDID Table Construction 

The table construction is divided into blocks dedicated to specifying various attributes. Each block is 128 
bytes in length. Block 0 is mandatory and the following blocks are called “extensions”. The extensions are 
limited to 254 blocks. 

It is possible to use the first extension as a data block or as an index (EDID Block Map Extension) that 
lists more than one extension. When only one extension is required, it is called Block 1 and is used for 
data. In cases where more than one extension is required, the first extension or Block 1 is used as an 
index map that lists extension locations. Additional extensions are referred to as Blocks, such as Block 2, 
Block 3, and so on. 

Each extension contains a Block Tag that declares the contents of each extension. Sources should read 
Block 0 (at address 0x7E), check for multiple extensions, identify each block or extension, and be able to 
appropriately interpret the data contained therein. Users should be knowledgeable of defined Tags 
contained within Section 2.2.1.4 of the VESA E-EDID standard. 

Sources should read all extensions and Block Tags. CTA Extension Version 1 or Version 3 specifies 
additional Video Formats as necessary. There are three possible versions of the CTA Extension and 
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Sources should read the contents of the extension even if they cannot recognize the version number. 
This is to insure that the Detailed Timing Descriptors are read. 

For CE devices, the number of extensions or blocks is dependent upon the amount of supported Video 
Formats and features. Annex A shows one extension containing four Detailed Timing Descriptors (see 
Section A.2.20). 

A.2.2 Detailed Explanation of EDID Block Zero 

For this discussion, block zero and subsequent extension blocks are divided into smaller sections, each 
receiving an explanation of terminology and use. The contents in each section are a possible example of 
a typical CE device application. 

A data format protocol is required to properly utilize the various blocks. Data within the various blocks is 
placed in fields with varying bit lengths. These lengths range from one bit to two bytes. The data length 
convention is defined and shown in Table 95 


Bit range 

Convention 

1 - 7 bits 

Binary, consecutive sequence 

8 bits (byte) 

Binary, according to location 

9 ~ 15 bits 

Binary, sequence according to field 


Binary, LSB first 

Greater than two bytes: 
(Character string) 

ASCII code, consecutive string order, ex: HDTV = 0x48, 0x44, 0x54, 0x56 


Table 95 Standard Data Lengths 

A.2.3 Block Zero Header Section 

The header is comprised of eight addresses, 0x00 through 0x07, containing a simple binary data pattern 
that is used to identify the EDID table. There is one byte per address for a total of eight bytes. Address 
locations 0x00 and 0x07 contain data values 0x00 and locations 0x01 through 0x06 contain OxFF as data 
values. CTA-861 requires this data. This header is used to determine the beginning of an EDID structure 
in a Sink. See Table 96. 


Address 

Hex 

Example Data 

Hex Dec 

Format 

Remarks 

0 x00 

0 x00 

0 

Binary 

These fixed values are 
REQUIRED to properly 
identify start of EDID table 
data 

0 x01 

OxFF 

255 

0 x02 

OxFF 

255 

0x03 

OxFF 

255 

0x04 

OxFF 

255 

0x05 

OxFF 

255 

0x06 

OxFF 

255 

0x07 

0 x00 

0 


Table 96 Block Zero Header 

Although future versions of EDID may not contain an 8-byte header at the beginning of Block 0, compliant 
devices are expected to use this header. However, presence of the header is not an indication that the 
following EDID data is valid. A checksum byte is provided for the purpose of verifying that a device’s 
EDID structure has been correctly read. See Section A.2.11 for more detail. 

A.2.4 Vendor / Product Identification 

This section’s example starts and ends with address locations 0x08 and 0x11. Byte allocation for each 
location is as follows: 

0x08 ~ 0x09 are a two byte PNP ID for Manufacturer Name and should contain a valid identification 
number. Data for these bytes is based upon compressed ASCII, for example: “CTA” is created by using 
five-bit codes, where “C” = 00011. “E” = 00101, and “A” = 00001. Table 3 illustrates the address location 
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and sample data for Manufacturer’s Name, which is “CTA”. For information on how to obtain a PNP ID, 
see Unified Extensible Firmware Interface Forum - PNP ID AND ACPI ID REGISTRY [90]. 

OxOA ~ OxOB are two bytes available for Product code; the manufacturer determines this code. 

OxOC ~ OxOF are four bytes to be used for product Serial Number, which is defined as a 32-bit serial 
number. There is no specific requirement defined for the data or format of the serial number. This field 
should be zero if the serial number is contained in an ASCII serial number descriptor (see Section 
A.2.17). CTA-861 implementations should use 0x00 as padding for the Block 0 serial number if no serial 
number is provided in Block 0. 

For the Source, if an ASCII Serial Number Descriptor is included in the Sink, then the Source should 
ignore the Serial Number field in Block 0. If no ASCII Serial Number Descriptor is present, then the field 
may have meaning. Ignore this block if all bytes are 0x00. 

0x10 is one byte for Week of Manufacture. The designated values for this field range from 1 to 53. Values 
greater than 53 are not recognized. Zero may be used when no week is designated. The manufacturer 
determines the week numbering system. Manufacturers should use a system in which the week number’s 
integer value increases as the year progresses. If a manufacturer chooses to declare only the Model Year 
(in the field "Year of Manufacture"), then OxFF shall be placed in Address 10 (Week of Manufacture). 

0x11 is one byte representing Year of Manufacture. This value is determined by the actual year of 
production minus 1990. For example: 2002 - 1990 = 12 or OxOC. See Table 97. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x08 

OxOC 

12 

Manufacturer Name 

using EISA ID 

Example = CTA 

0x09 

OxAl 

161 

OxOA 

0 x12 

18 

Product Code 

Used to differentiate 
between different models 
from the same 
manufacturer. In this 
example Product 
Code=0x3412 

OxOB 

0x34 

52 

OxOC 

0x56 

86 

Serial Number 

Optional. 

The serial number can also 
be stored in a separate 
descriptor block (see 

Section A.2.17). In this 
example, the Serial 
Number=0xBC9A7856. 

0x0 D 

0x78 

120 

0x0 E 

0x9A 

154 

OxOF 

OxBC 

188 

0 x10 

0 x10 

16 

Week of Manufacture 

If this field is unused, the 
value should be set to 0. If 
the next field is used for 
Model Year, then OxFF 
should be set. In this 
example Manufacture 
Week=16 

0 x11 

OxOC 

12 

Year of 

Manufacture/Model 

Year 

Example = Manufactured 
Year=2002 


Table 97 Vendor / Product Identification; Showing Manufacturer Week and year 
A.2.5 EDID Version 

The version of EDID is declared in addresses 0x12 and 0x13. Each address contains one byte of data. 
The first address contains the version number and the second, the revision number. In the case of EDID 
version 1, revision 3, the value one (0x01) is placed in the first location (i.e., 0x12) and three (0x03) 
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placed in the second area (0x13). No other numbers are allowed for this space. If other numbers are 
placed in this area, the Source may disregard the whole EDID table. See Table 98. 


Address 

Hex 

Example Data 

Hex Dec 

Format 

Remarks 

0x12 

0x01 

1 

Binary 

Version # 

0x13 

0x03 

3 

Revision # 


Table 98 Vendor / Product Identification 


A.2.6 Basic Display Parameters and Features 

Basic Display Parameters and Features are defined as Video Input Definition, Maximum Horizontal Image 
Size, Maximum Vertical Image Size, Display Transfer Characteristic (Gamma), and Feature Support. In 
the following example, each item is allocated one byte and the address range is from 0x14 to 0x18. 

0x14: Video Input Definition is located at 0x14 and used to identify the output configuration required by 
the Sink. For digital displays, including CE devices, the recommended setting is 0x80. This value is used 
to declare that the device supports a digital interface. 

0x15 ~ 0x16: The Maximum Horizontal Image Size and Vertical Image Size fields (bytes 0x15, 0x16) are 
used to indicate the Sink’s screen size and aspect ratio. When known, the maximum physical dimensions 
of the effective display area should be provided (in these fields, in cm). An important use of these fields is 
to indicate the aspect ratio of the actual screen. If the aspect ratio of the maximum image size is known, 
the ratio of the Maximum Size fields (H/V) should equal that aspect ratio, even if the maximum image size 
is unknown or variable across different device configurations (such as in a projection system). 

The following rules should be used in filling out the Maximum Image Size fields: 

a) If the aspect ratio is known and the display size is known, then the actual size should be indicated, to 
the nearest cm. 

b) If the aspect ratio is known but the size is unknown, any values corresponding to a typical or 
expected configuration of the display can be used, but the ratio of the Max Horizontal and Vertical 
fields shall be equal to the aspect ratio. 

c) If the aspect ratio is unknown, or it is desired that it not be discoverable, then values of 0, 0 should be 
used. 

If the fields are set to zero, the Source should not make any assumptions regarding screen size or aspect 
ratio. 

In typical configurations, the image sizes described in each DTD (in bytes at offsets OxOC, OxOD, OxOE, in 
mm) should correlate to the values in the Maximum Size fields. For instance, a 160 cm by 90 cm display 
would indicate 1600 mm x 900 mm for all 16:9 Video Formats and 1200 mm x 900 mm for all 4:3 formats. 

For example, data entry into the 0x15, 0x16 EDID bytes may be as summarized in Table 99. 


Category of Display 

EDID Physical 

Horizontal 

Screen Size (cm) 

EDID Physical Vertical 
Screen Size (cm) 

Physical AR to be 
calculated by the Source 
(unit less) 

Direct View 

Enter dimension in cm 

Enter dimension in cm 

Source Divides H by V 

Rear Projector 

Enter dimension in cm 

Enter dimension in cm 

Source Divides H by V 

Front Projector 
(enter either data row 
at option of implementer) 

Typical dimension in cm 

Typical dimension in cm 

Source Divides H by V 

Enter 0x00 

Enter 0x00 

AR is undefined 


Table 99 Example 0x15, 0x16 EDID Screen Size Data and Certain Display Categories 
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0x17: Display Transfer Characteristics (Gamma) could be used by the Source to tailor the video output 
according the display device’s gamma. The concept of declaring gamma has to do with personal 
computer CRT displays that accept non-gamma corrected signals. Digital and analog television video 
signals are gamma corrected according to established industry practices and thus the need to declare 
CRT gamma is not always necessary. However, this is needed for Personal Computer CRT applications. 
Although the Source possibly may not need to use the display’s gamma value, the correct gamma value 
of the display device should be present. Since some television CRTs commonly have similar gamma, the 
value 2.2 is used in this example. The gamma value, itself, is not inserted into the table. Instead, a value 
equal to (gamma x 100) - 100 is inserted. 

0x18: Feature Support consists of 8 bits that identify various display or Sink parameters. These include 
power savings modes based upon VESA Display Power Management Signaling Standard (DPMS), 
Display Type, Standard Default Color Space, Preferred Timing Mode, and Default Generalized Timing 
Formula (GTF). In most cases, none of this information is relevant to CE devices and personal computer 
displays, since GTF is not commonly used. In Table 100, the function of each bit is indicated. 


Bits 

Feature 

Description 

7 

Standby 

1 = Standby supported, 

0 = not supported 

6 

Suspend 

1 = Suspend supported, 

0 = not supported 

5 

Active Off 

1 = Active Off supported, 

0 = not supported 

■ 

Display Type (4:3) 

Bit 4 Bit 3 I 

1 1 Undefined 

1 0 Non-RGB Display 

0 1 RGB Display 

0 0 Monochrome Display 

2 

Color Space 

1 = sRGB supported, 

0 = not supported 

1 

Preferred Timing 

1 = preferred timing is indicated in first 
detailed timing block (required), 

0 = not indicated (not allowed) 

0 

Default GTF 

1 = GTF supported, 

0 = not supported 


Table 100 Feature Support Detail 

The minimum that a CE device should declare is Display Type and Preferred Timing. In this example, 
OxOA is used to designate a RGB display type and a preferred timing descriptor. The preferred timing 
descriptor bit shall be set to one and address locations 0x36 through 0x47 shall contain the Preferred 
Format. No other data is allowed in those locations. All DTDs and SVDs shall be listed in order of priority; 
meaning that the first is the one that the display manufacturer has identified as optimal; however, in the 
context of total system optimization, Source implementers are advised to follow guidance provided in 
Section 7.2.3. 
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Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x14 

0x80 

128 

Video Input Definition 

Example indicates: 

Digital; 

VESA DFP1X: not compatible 

0x15 

0x50 

80 

Max. Horizontal Image 
Size in cm 

CRT devices should list 
parameters. However, due to 
projector and auto sizing 
devices, the system should 
not make any assumption 
regarding display size if data 
not supplied. This example 
indicates a 16:9 aspect ratio 
device. 

0x16 

0x2 D 

45 

Max. Vertical Image 

Size in cm 

Optional; See above; This 
example indicates a 16:9 
aspect ratio device. 

0x17 

0x78 

120 

Gamma: (gamma x 

100)-100 = value 

Example is: (for gamma = 2.2) 
(2.2 x 100)-100 = 120 

0x18 

OxOA 

10 

Feature Support 

Example indicates: 

RGB color Display type; 
Preferred timing: first detailed 
timing block; 

GTF timing: not supported; 
Standby mode: not supported; 
Suspend mode: not 
supported; 

Active off: not supported 


Table 101 Basic Display Parameters and Features Block 
A.2.7 Color Characteristics 

Color Characteristics provides information about the display device’s chromaticity and color temperature 
parameters (white temperature in degrees Kelvin). 

Table 103 shows EDID addresses 0x19 through 0x22, which contain data used to describe various 
chromaticity characteristics; this example uses 9300° K as the white color temperature. These 
characteristics are represented by 10-bit binary fractions. Bits nine through two of a particular 
characteristic are stored as a single byte in addresses 0x1 B ~ 0x22. Bits one to zero of that 
corresponding characteristic are paired with the lower order bits of other color characteristics to form 
bytes and are stored in addresses 0x19 ~ 0x1 A. Table 103 shows the arrangement of these fractional 
binary values by EDID address. In the E-EDID standard, a decimal fraction such as 0.625 is represented 
by a 10-bit binary value. Each of the bit positions from left to right in the binary value represent powers of 
2 from 2 -1 ~ 2 -10 . Table 102 illustrates an example decimal to binary conversion used for these color 
characteristics. Further explanation can be found in VESA E-EDID [9] Section 3.7. 


Value 

10-bit Binary 

Conversion 

0.625 

1010000000 

0.625 i 

0.340 

0101011100 

0.33984375 

0.155 

0010011111 

0.1552734375 I 


Table 102 Binary to Decimal Conversion Example 

How the table is filled is dependent upon the setting of address 0x18 in the Feature Support section. If 
sRGB is selected, then all values should be set in accordance to sRGB definition. For displays not 
supporting the sRGB definition, the example in Table 103 is applicable. 


126 

















CTA-861-G 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x19 

0x0 D 

13 

Red/Green Low Bits 

Bits 1-0 of RxRyGxGy = 
00001101 

0x1 A 

0xC9 

201 

Blue/White Low Bits 

Bits 1-0 of BxByWxWy = 
11001001 

0x1 B 

OxAO 

160 

Red-x 

Bits 9-2 of 10-bit value 0.625 
=10100000 

0x1 C 

0x57 

87 

Red-y 

Bits 9-2 of 10-bit value 0.340 
=01010111 

0x1 D 

0x47 

71 

Green-x 

Bits 9-2 of 10-bit value 0.280 
=01000111 

0x1 E 

0x98 

152 

Green-y 

Bits 9-2 of 10-bit value 0.595 
=10011000 

0x1 F 

0x27 

39 

Blue-x 

Bits 9-2 of 10-bit value 0.155 
= 00100111 

0x20 

0x12 

18 

Blue-y 

Bits 9-2 of 10-bit value 0.070 
= 00010010 

0x21 

0x48 

72 

White-x 

Bits 9-2 of 10-bit value 0.283 
=01001000 

0x22 

0x4C 

76 

White-y 

Bits 9-2 of 10-bit value 0.298 
=01001100 

Note—This data based on a CRT Display with a white point of -9300° K (X = 0.283; Y = 
0.298) 


Table 103 Color Characteristics Block 


Multiple white points can be specified using the Color Point Monitor Descriptor. However, there is no way 
to correlate to the individual Video Formats. Therefore chromaticity specified in Block 0 should be 
associated with the display device’s characteristics; however the White Point data does not. The Source 
should not rely on the colorimetry information contained in this part of the EDID data structure for CTA- 
861 formats. This recommended practice suggests the Source use the colorimetry that has been 
associated with the format in CTA-861 when possible. Note that this may not be possible because the 
Source probably just passes on the video stream. 

A.2.8 Established Timings 

In the example in Table 104, addresses 0x23 through 0x25 are used to declare Established Timings. 
Established Timings are computer display timings recognized by VESA. This table is also used to indicate 
that the established timings were adjusted and verified at the factory, which means these timings are 
supported and correctly rendered on the display. 

In the example, Table 104, address 0x23 contains the default 640x480p timing and the remaining 
addresses are not used to list any other timings. Personal Computers, DVI-1.0 [4], Open LDI [8], CTA-861 
require 640x480p as a default timing format. This is to insure that all Sources and Sinks commonly 
support one format. Other supported or preferred timings may be described in the Standard Timing (see 
A.2.9) or Detailed Timing Descriptors (see A.2.10). Use of other timings is permissible. See VESA E- 
EDID Section 3.8.1 [9] for a list of possible formats. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x23 

0x20 

32 

Established Timing 1 

640x480 @ 60Hz 

0x24 

0x00 

0 

Established Timing 2 

None 

0x25 

0x00 

0 

Manufacturer's Timing 

None 


Table 104 Established Timings Block 
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A.2.9 Standard Timing ID #1 - 8 

Standard timings are those either recognized by VESA through the VESA Discrete Monitor Timing or 
Generalized Timing Formula standards. The display device should list timings supported. The address 
range for this portion of the example EDID table is 0x26 through 0x35 and the data length is two bytes. 

Since CE devices possibly may not support, other than the required 640x480p format, any of the VESA 
timings or GTF, the example in Table 105 does not contain any timing information. When no timings are 
declared, it is necessary to fill each unused byte, of the byte pairs, with 0x01 as padding. Other padding 
values are not recognized. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x26 

0x01 

1 

Standard Timing ID #1 

PC Application 

0x27 

0x01 

1 

0x28 

0x01 

1 

Standard Timing ID #2 

PC Application 

0x29 

0x01 

1 

0x2A 

0x01 

1 

Standard Timing ID #3 

PC Application 

0x2 B 

0x01 

1 

0x2C 

0x01 

1 

Standard Timing ID #4 

PC Application 

0x2 D 

0x01 

1 

0x2 E 

0x01 

1 

Standard Timing ID #5 

PC Application 

0x2 F 

0x01 

1 

0x30 

0x01 

1 

Standard Timing ID #6 

PC Application 

0x31 

0x01 

1 

0x32 

0x01 

1 

Standard Timing ID #7 

PC Application 

0x33 

0x01 

1 

0x34 

0x01 

1 

Standard Timing ID #8 

PC Application 

0x35 

0x01 

1 


Table 105 Standard Timing ID Block 
A.2.10 Detailed Timing Descriptor Block 

The detailed timing section is 72 bytes in length and can be divided into four descriptor blocks, which are 
each 18 bytes. In the following example, the address ranges for these four blocks are 0x36-0x47, 0x48- 
0x59, 0x5A-0x6B and 0x6C-0x7D. Each of these descriptors contains either detailed timing data (Detailed 
Timing Descriptor) or other specific types of data as described in the VESA E-EDID standard. 

The VESA E-EDID standard allows various descriptor sequences, combinations, or repetitions and 
Sources should handle descriptors that may appear in any order. The only prescribed constraint is that 
Detailed Timing Descriptors precede the two required Monitor Descriptors in Block 0. The descriptors 
require the presence of valid data and no fill patterns are permitted in Block 0. Therefore, the Source 
should handle these possibilities and requirements accordingly. Blocks used for data, not detailed timing 
information, have a five byte identifier header that is formatted as follows: 0x00, 0x00, 0x00, <Tag #>, 
0x00. For more detail regarding 18-byte descriptor tags, please refer to the VESA EDID standard section 
3.10.3 [9], 

The example in CTA-861 configures the four blocks in this order: First Detailed Timing Descriptor, Second 
Detailed Timing Descriptor, First Monitor Descriptor (Monitor Name), and Second Monitor Descriptor 
(Monitor Range). 

A.2.10.1 First Detailed Timing Descriptor 

The VESA E-EDID Standard [9] requires that the First Detailed Timing Descriptor be used for the most 
“preferred” Video Format and subsequent detailed timing descriptors are listed in order of decreasing 
preference. 
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Data locations within the Detailed Timing Descriptors are used to specify the Video Timing characteristics, 
image size, and contain flags for identifying interlace/non-interlace formats and sync signal polarities. 
Designers of Source and Sink need to carefully consider these types of data in all implementations. 

The example in Table 106 shows the data format for a Preferred Video Format of 1920x1080i and the 
image size is matched to the screen size of approximately 36 inches diagonal. CTA-861 recommends 
listing exact horizontal and vertical dimensions, but at least requires values that describe the aspect ratio. 
The Source should be capable of using these dimensions to determine aspect ratio. However, some 
EDID implementations that do not provide horizontal and vertical dimensions for non-CTA-861 Video 
Formats may be encountered. The flags are set to convey an interlaced format and the syncs as separate 
and of positive polarity. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

(Refer to note below for additional details) 

0x36 

0x01 

1 

Pixel Clock 

74.25 MHz 

0x37 

0x1 D 

29 

0x38 

0x80 

128 

H Active 

1920 pixels 

0x39 

0x18 

24 

H Blanking 

280 pixels 

0x3A 

0x71 

113 

H Active: H Blanking 


0x3 B 

0x1 C 

28 

V Active 

540 lines 

0x3C 

0x16 

22 

V Blanking 

22 lines 

0x3 D 

0x20 

32 

V Active: V Blanking 


0x3 E 

0x58 

88 

H Sync Offset 

88 pixels 

0x3 F 

0x2C 

44 

H Sync Pulse Width 

44 pixels 

0x40 

0x25 

37 

VS Offset: VS Pulse 

Width 

2 lines, 5 lines 

0x41 

0x00 

0 

HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


0x42 

0x20 

32 

H Image Size 


0x43 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0x44 

0x31 

49 

H&V Image Size 

Upper 4 bits of H Size; 

Upper 4 bits of V Size 

0x45 

0x00 

0 

H Border 

0 pixels 

0x46 

0x00 

0 

V Border 

0 lines 

0x47 

0x9 E 

158 

Flags 

Interlaced, normal display no stereo, digital 
separate, Vsync polarity is positive, Hsync 
polarity is positive 


NOTE—Some addresses above contain “composite” bytes representing high and/or low order bits or 
“nibbles” (4 bits of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on 
these fields. 


Table 106 First Detailed Timing Descriptor Block (1920x1080i Example) 
A.2.10.2 Second Detailed Timing Descriptor 

Table 107 contains an example for the second preferred timing using the Second Detailed Timing 
Descriptor block. This is the SDTV 720x480p format that has a 4:3 aspect ratio. 
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Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

(Refer to note below for additional details) 

0x48 

0x8C 

140 

Pixel Clock 

27 MHz 

0x49 

OxOA 

10 

0x4A 

OxDO 

208 

H Active 

720 pixels 

0x4 B 

0x8A 

138 

H Blanking 

138 pixels 

0x4C 

0x20 

32 

H Active: H Blanking 


0x4 D 

OxEO 

224 

V Active 

480 lines 

0x4 E 

0x2 D 

45 

V Blanking 

45 lines 

0x4 F 

0x10 

16 

V Active: V Blanking 


0x50 

0x10 

16 

H Sync Offset 

16 pixels 

0x51 

0x3 E 

62 

H Sync Pulse Width 

62 pixels 

0x52 

0x96 

150 

VS Offset: VS Pulse 

Width 

9 lines, 6 lines 

0x53 

0x00 

0 

HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


0x54 

0x58 

88 



0x55 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0x56 

0x21 

33 

H&V Image Size 

Upper 4 bits of H Size; 

Upper 4 bits of V Size 

0x57 

0x00 

0 

H Border 

0 pixels 

0x58 

0x00 

0 

V Border 

0 lines 

0x59 

0x18 

24 

Flags 

Non-interlaced, normal display no stereo, digital 
separate, V. and H. sync polarity is negative 


NOTE—Some addresses above contain ‘composite’ bytes representing high and/or low order bits or “nibbles” (4 
bits of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 


Table 107 Second Detailed Timing Descriptor Block (720x480p, 4:3 Example) 

A.2.10.3 First Monitor Descriptor (Monitor Name) 

The VESA Standard [9] requires that one of the four 18-byte descriptors be a Monitor Name Descriptor. 
Here, it is recommended that the third 18-byte descriptor be used as the First Monitor Descriptor or 
Monitor Name. Examples of these bytes are located at addresses 0x5F through 0x6B. Each location is 
one byte in length and is used for ASCII character string. In the example contained in Table 108, a 
fictitious Monitor Name is listed. 
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Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x5A 

0x00 

0 

Flag (REQUIRED) 

Flag = 0x0000 when block used as 
descriptor 

0x5 B 

0x00 

0 

0x5C 

0x00 

0 

Flag (Reserved) 

Flag = 0x00 when block used as 
descriptor 

0x5 D 

OxFC 

252 

Data Type Tag 

OxFC denotes that last 13 bytes of 
this descriptor block contain Monitor 
name 

0x5 E 

0x00 

0 

Flag 

Flag = 0x00 when block used as 
descriptor 

0x5 F 

0x4 D 

77 

ASCII coded monitor 
name (13 bytes max). 

If name < 13 bytes, 
terminate name with 

OxOA and fill remainder 
of 13 bytes with 0x20. 

Example monitor name: 

“MY HDTV” 

0x60 

0x59 

89 

0x61 

0x20 

32 

0x62 

0x48 

72 

0x63 

0x44 

68 

0x64 

0x54 

84 

0x65 

0x56 

86 

0x66 

OxOA 

10 

0x67 

0x20 

32 

0x68 

0x20 

32 

0x69 

0x20 

32 

0x6A 

0x20 

32 

0x6 B 

0x20 

32 


Table 108 First Monitor Descriptor Block (Monitor Name) 

A.2.10.4 Second Monitor Descriptor (Monitor Range Limits) 

The next and last 18-byte descriptor within Block 0 should be used as the Second Monitor Descriptor. In 
this example, it is the Monitor Range Limit, which is used to designate minimum and maximum 
parameters for horizontal and vertical frequencies and maximum pixel clock rate. In the following 
example, the block of data ranges from 0x6C through 0x7D. The data format is binary coded integer. 

The first three locations, 0x6C (Flag), 0x6D (Flag), and 0x6E (Reserved Flag) are set to zero. Address 
0x6F, a Data Type Flag, should be set to OxFD, which means, “monitor range limits, binary coded.” For 
more detail, please refer to the VESA E-EDID standard Section 3.10.3 [9]. Address 0x70 is another flag 
and loaded with zero. 

Locations 0x71 through 0x75 are used to designate the minimum and maximum parameters for horizontal 
and vertical frequencies, and maximum pixel clock. Table 109 contains an example for a DTV that 
supports a 60 Hz vertical refresh rate, 15 kHz up to 46 kHz horizontal rates, which cover the frequencies 
required for 720x480i, 720x480p, 1280x720p and 1920x1080i formats having a maximum pixel clock of 
80 MHz. 

For EDID (Version 1, Revision 3), inclusion of the Monitor Range Limits in base EDID (Block 0) does not 
imply that the Sink is multi-scan capable 

NOTE—To reduce the possibility that a Source would mistakenly ignore the frequency range data 
if the minimum and maximum values were equal, a range of horizontal and vertical frequencies 
should be declared. For example, if a device supports only 15.75 kHz and 60 Hz timing, it is 
recommended to list the range as 15 to 16 kHz and 59 to 61 Hz. Sources may encounter legacy 
devices that specify the same value for MIN and MAX horizontal and/or vertical ranges. 
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Address 

Hex 

Example Data 
Hex Dec 

Description 

Remarks 

0x6C 

0x00 

0 

Flag 

Flag = 0x0000 when block 
used as descriptor 

0x6 D 

0x00 

0 

0x6 E 

0x00 

0 

Flag (Reserved) 

Flag = 0x00 when block 
used as descriptor 

0x6 F 

OxFD 

253 

Data Type Tag 

FDh denotes that last 13 
bytes of this descriptor block 
contain Monitor Range 
limits, binary coded 

0x70 

0x00 

0 

Flag 

Flag = 0x00 when block 
used as descriptor 

0x71 

0x3 B 

59 

Min Vertical Rate in Hz 

59 HZ 

0x72 

0x3 D 

61 

Max Vertical Rate in Hz 

61 Hz 

0x73 

0x0 F 

15 

Min Horizontal Rate in kHz 

15 kHz 

0x74 

0x2 E 

46 

Max Horizontal Rate in kHz 

46 kHz 

0x75 

0x08 

8 

Max Supported pixel clock rate 
in MHz/10 

80 MHz 

0x76 

0x00 

0 

Tag for secondary timing 
formula (0x00=not used) 

No secondary timing formula 
supported 

0x77 

OxOA 

10 

Put OxOA after last data byte in 
block and fill remaining bytes 
with 0x20. 

Unused data address 

0x78 

0x20 

32 

0x79 

0x20 

32 

0x7A 

0x20 

32 

0x7 B 

0x20 

32 

0x7C 

0x20 

32 

0x7 D 

0x20 

32 


Table 109 Second Monitor Descriptor Block (Monitor Range Limits) 

Address 0x76 is used as a tag for a secondary generalized timing formula (GTF) and is not typically used 
for CE devices. In this case, the flag is set to zero. Addresses 0x77 through 0x7D are related to this tag. 
The E-EDID standard requires that address 0x77 contain OxOA and addresses 0x78 ~ 0x7D contain 0x20 
when no secondary GTF data is provided. 

A.2.11 Extension Flag and Checksum 

The Extension Flag and Checksum are defined as two-byte data located in address range 0x7E through 
0x7F. The Extension Flag is used to indicate that additional blocks are present in the EDID that declare 
additional Video Formats and other monitor features. 

The Extension Flag is used to declare the number of extensions that exist within the EDID tables. The 
total number of extensions actually present should equal the number of extensions declared within the 
base EDID. The number of extensions declared in the base EDID shall not include the base EDID, but 
shall include the block map. For example, if no extensions exist in the EDID data, then the Extension Flag 
shall be set to zero. If a single (e.g., CTA) extension is present, then the flag shall be set to one. If two 
(e.g., CTA) extensions are used, then a block map extension is also required by VESA EDID standard— 
increasing the total number of extensions to three. In this case, the extension flag is set to 3 and the Sink 
has an EDID containing a total of four 128-byte blocks: a base block plus three extensions—the first 
extension being a block map. 

NOTE—Some devices have been incorrectly designed so that the block map is not counted in the 
extension count. Design of compliant devices should take compatibility with those non-compliant 
devices into consideration. For example, when a Source finds an extension count of 2, it may 
attempt to read 3 extensions on the chance that the Sink has incorrectly set its count, or it may 
use the information in the block map as a more accurate guide. 

The Checksum is set so that the sum of the entire 128-byte block modulus 256 equals 0x00. Sink 
designers should calculate checksum using the following formula: 
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Checksum byte = (256-(S%256)) %256 
Where: 

S is the sum of the first 127 bytes 
% is modulus operator 

Table 110 contains example data based upon the tables presented in CTA-861. The Extension Flag at 
location 0x7E is set to one declaring that Block 1 is present. Since the Extension Flag equals 1 in the 
example, no other blocks exist. The Checksum is set so that the sum modulus 256 of the entire 128-byte 
block equals 0x00. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x7 E 

0x01 

1 

Extension Flag 

Number of 128 bytes blocks 
to follow 

0x7 F 

0xC3 

195 

Checksum 

Block 0 sum (address 
0x00~0x7E) = 0x1 B3D 


Table 110 Extension Flag Block 


A.2.11.1 Block One Details 

Although there may be DTV implementations that do not include a CTA Extension or that include it in a 
block other than Block 1, it is recommended that for a CTA-861 implementation, that the CTA Extension 
be included in Block 1. Therefore, the remainder of Annex A (through Section A.4) assumes that Block 1 
is a CTA Extension. 

One purpose of the CTA Extension is to provide a place to add additional Detailed Timing Descriptors. 
However, other VESA-defined 18-byte descriptors are possible (e.g., Monitor Serial Number, 

Manufacturer Specific, etc.). Sources should ignore descriptors that they do not understand. The only 
descriptors that a CTA-861 Source is required to understand are the Detailed Timing Descriptors, the 
Monitor Range Limit descriptor, and the Monitor Name Descriptor. Note that the handling of unused 
descriptors is different in the CTA Extension than it is in Block 0. In Block 0, all four descriptor blocks are 
required by VESA EDID standard [9] to be filled with valid data, even if it means repeating a timing 
descriptor. In the CTA Extension, unused descriptor locations are all collected at the end and filled with a 
fill pattern of 0x00. Technically, a descriptor that has the first bytes being 0x00 would be a manufacturer- 
defined descriptor with a tag of 0x00. It is recommended that manufacturers avoid the use of a 0x00 tag. 
Sources should verify that there are eighteen 0x00 bytes following the last valid descriptor if there is 
enough room for a descriptor. It is also recommended that the DTV place all of its remaining Detailed 
Timing Descriptors before other descriptors in the CTA Extension. 

Within the CTA Extension, per CTA-861, up to six Detailed Timing Descriptors are allowed and may occur 
in any order. Therefore, Sources should be able to handle any combination or sequence that these 
Detailed Timing Descriptors may appear. According to CTA-861, the timing of highest priority is listed first, 
with subordinate timings listed after in descending order. Sources should be capable of skipping 
additional extensions that they may not understand when encountered within Block 1. 

A.2.12 Overview of Extensions 

VESA has assigned Extension Tags to identify EDID extensions and Sources should anticipate 
encountering some of these extensions. Extensions are identified by the first byte (i.e., Tags). The Tags 
indicate the type of extension and its purpose. CTA-861 implementations are required to use Tag = 0x02 
for the CTA Extension Tag and Sources should ignore Tags that are not understood. 

In the subsequent sections of this Annex (excepting Section A.2.19), an example is given utilizing CTA 
Extension block version 1. Version 3 of the CTA Extension is most common and is required for HDMI 
implementations. For HDMI implementations, extension block version 3 is required. An example of 
version 3 is given in Annex D.6. See Section 7.1 for additional guidance on the use of specific versions. 
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A.2.13 Block One CTA Extension Header 

The CTA Extension Header is defined as four-byte data located in the first four bytes of the EDID block. 
The first byte is the tag used to identify the extension. The number assigned by VESA to this tag is 0x02. 
Following the CTA Extension Tag is the Revision Number location. The data for Revision Number was set 
according to which standard version the Sink was designed to support. The January 2001 release of 
CTA-861, CTA-861-A, and CTA-861-B all had unique number assignments for the Revision Number and 
this was used to differentiate the level of supported features, such as ”lnfoPackets“, audio, etc. Beginning 
with CTA-861-C and continuing through present, incrementing the version number is no longer required. 
The revision number shall be set to 0x03. 

Note that the January 2001 release of CTA-861 and CTA-861-A required the revision number to be set to 
0x01 and 0x02, respectively. See Section 7.1 for further guidance. Versions 2 and 3 of the CTA Extension 
are backward compatible with version 1, which is illustrated in this example. 

Sources should be prepared to read versions later than version 1 and properly interpret the required 18- 
byte descriptors. 

Following the Revision Number is the Byte Number Offset. This is used to tell where the Detailed Timing 
Data begins following the Reserved Data Block. The Source should use this byte offset to skip fields that 
it may not understand within the CTA Extension when encountering versions of this extension that may 
be newer than its own. CTA-861 Sinks should load location 82 with d = 4 if the extension includes 18-byte 
descriptors. In the following example, the data is listed as 0x04, which means there is no data present in 
the Reserved Data Block and that there are 18-byte descriptors present starting at the fifth byte of the 
EDID block. 

Sources should be aware that for later versions of the CTA Extension, d may be set to something other 
than 0 when no 18-byte descriptors are present. This is an indication that there is data in the reserved 
data block. In such a case, d would be set to the location where 18-byte detailed timing descriptors would 
be located if present. That data should be skipped by a CTA-861 Source. The presence of padding data 
for 18-byte descriptors can be used by the Source as an indication whether 18-byte descriptors are 
present or not. 

The data at the next address location, 0x83 in this example, is reserved in the CTA Extension Version 1 
(used for an 861 implementation) and is required in 861 to be set to 0x00. Newer versions of the CTA 
Extension include flags in this field (see Sections 7.3 and 7.4). These flags can be ignored by a CTA-861 
Source. 

Table 111 contains example data based upon the tables presented in CTA-861. In this example, the CTA 
Extension Tag is located at 0x80 followed by Revision Number, Byte Number Offset, and Reserved (i.e., 
0x00). The data is set as prescribed by CTA-861. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0x80 

0x02 

2 

Tag per CTA-861 

Tag 0x02 assigned by VESA to 
CTA for this extension 

0x81 

0x01 

1 

0x01 per CTA-861 

Indicates revision of CTA-861 
used by this device 

0x82 

0x04 

4 

0x04 per CTA-861 

0x04 indicates no data present in 
Reserved Data Block; 18-byte 
descriptors ARE present 

0x83 

0x00 

0 

0x00 per CTA-861 

These bits are utilized as flags in 
later versions of CTA-861 


Table 111 Block One CTA Extension Header 
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A.2.14 Third Detailed Timing Descriptor 

Following the Extension Flag Table is the next or Third Detailed Timing Descriptor. Table 112 follows the 
same format as with Table 106 and Table 107. This example is for HD format 1280x720p. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

(Refer to note below for additional details) 

0x84 

0x01 

1 

Pixel Clock 

74.25 MHz 

0x85 

0x1 D 

29 

0x86 

0x00 

0 

H Active 

1280 pixels 

0x87 

0x72 

114 

H Blanking 

370 pixels 

0x88 

0x51 

81 

H Active: H Blanking 


0x89 

OxDO 

208 

V Active 

720 lines 

0x8A 

0x1 E 

30 

V Blanking 

30 lines 

0x8 B 

0x20 

32 

■'lllll'IH'l INI HIM 


0x8C 

0x6 E 

110 

H Sync Offset 

110 pixels 

0x8 D 

0x28 

40 

H Sync Pulse Width 

40 pixels 

0x8 E 

0x55 

85 

VS Offset: VS Pulse 

Width 


0x8 F 

0x00 

0 

HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


0x90 

0x20 

32 

H Image Size 

800 mm (lower 8 bits) 

0x91 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0x92 

0x31 

49 

H&V Image Size 

Upper 4 bits of H Size; 

Upper 4 bits of V Size 

0x93 

0x00 

0 

H Border 

0 pixels 

0x94 

0x00 

0 

V Border 

0 lines 

0x95 

0x1 E 

30 

Flags 

Non-interlaced, normal display no stereo, 
digital separate, H and V sync polarity is 
positive 


NOTE—Some addresses above contain ‘composite’ bytes representing high and/or low order bits or 
“nibbles” (4 bits of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details 
on these fields. 


Table 112 Third Detailed Timing Descriptor Block (720p, 16:9 Example) 

A.2.15 Fourth Detailed Timing Descriptor 

After the Third Detailed Timing Descriptor, the next Detailed Timing Descriptor follows, as indicated in 
Table 113. As with Table 106, Table 107 and Table 112, the same format is used. This table declares the 
SD 720x480i format, which requires doubling the horizontal pixel count to meet the DVI 1.0 minimum 
pixel clock frequency. 
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Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

(Refer to note below for additional details) 

0x96 

0x8C 

140 

Pixel Clock 

27 MHz 

0x97 

OxOA 

10 

0x98 

OxAO 

160 

H Active 

1440 pixels 

0x99 

0x14 

20 

H Blanking 

276 pixels 

0x9A 

0x51 

81 

H Active: H Blanking 


0x9 B 

OxFO 

240 

V Active 

240 lines 

0x9C 

0x16 

22 

V Blanking 

22 lines 

0x9 D 

0x00 

0 

V Active: V Blanking 


0x9 E 

0x26 

38 

H Sync Offset 

38 pixels 

0x9 F 

0x7C 

124 

H Sync Pulse Width 

124 pixels 

OxAO 

0x43 

67 

VS Offset: VS Pulse 

Width 


OxAl 

0x00 

0 

HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


0xA2 

0x58 

88 

H Image Size 


0xA3 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0xA4 

0x21 

33 

H&V Image Size 

Upper 4 bits of H Size; 

Upper 4 bits of V Size 

0xA5 

0x00 

0 

H Border 

0 lines 

0xA6 

0x00 

0 

V Border 

0 pixels 

0xA7 

0x98 

152 

Flags 

Interlaced, normal display no stereo, digital 
separate, V. and H. sync polarity is negative, 


NOTE—Some addresses above contain ‘composite’ bytes representing high and/or low order bits or “nibbles” (4 
bits of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 


Table 113 Fourth Detailed Timing Descriptor Block (480i, 4:3 Example) 

A.2.16 Descriptor Defined by Manufacturer 

The Descriptor Defined by Manufacturer Table is placed after the last Detailed Timing Descriptor. The 
manufacturer defines the contents of this descriptor. The tag can be any value between 0x00 and OxOF 
although the use of 0x00 is not recommended as explained in Section 4.3. The example in Table 114 
illustrates data that declares a revision number. 
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Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

0xA8 

0x00 

0 

Flag 


0xA9 

0x00 

0 

Flag 


OxAA 

0x00 

0 

Reserved 


OxAB 

0x01 

1 

Data Type 01-0F 


OxAC 

0x00 

0 

Flag 


OxAD 

0x52 

82 

R 


OxAE 

0x45 

69 

E 


OxAF 

0x56 

86 

V 


OxBO 

0x31 

49 

1 


OxBI 

0x2 E 

46 



0xB2 

0x30 

48 

0 


0xB3 

0x30 

48 

0 


0xB4 

OxOA 

10 



0xB5 

0x00 

0 



0xB6 

0x00 

0 



0xB7 

0x00 

0 



0xB8 

0x00 

0 



0xB9 

0x00 

0 




Table 114 Descriptor Defined by Manufacturer Block 
A.2.17 Monitor Serial Number 

13 bytes of this 18-byte table are allocated for the Monitor Serial number. This table can be used for the 
manufacturer’s convenience. The monitor serial number descriptor uses OxFF as the tag. Tags are 
described in Section 4.2.8. The data should be ASCII based. Table 115 contains a fictitious serial number 
as an example. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

OxBA 

0x00 

0 

Flag 

Flag = 0x0000 when block used as 
descriptor | 

OxBB 

0x00 

0 

OxBC 

0x00 

0 


Flag = 0x00 when block used as descriptor 

OxBD 

OxFF 

255 

Serial Number Tag 

Refer to VESA E-EDID standard, Section 
3.10.3 for tag definitions 

OxBE 

0x00 

0 

Flag 


OxBF 

0x39 

57 

ASCII serial number data 

‘9’ 

OxCO 

0x39 

57 

‘9’ 

OxCI 

0x46 

70 


0xC2 

0x43 

67 

‘C’ 

0xC3 

0x35 

53 

‘5’ 

0xC4 

0x30 

48 

‘0’ 

0xC5 

0x30 

48 

‘0’ i 

0xC6 

0x30 

48 

‘0’ 

0xC7 

0x31 

49 

‘1’ 

0xC8 

OxOA 

10 

ASCII Line Feed 

0xC9 

0x20 

32 

Padding (ASCII space) 

OxCA 

0x20 

32 

Padding (ASCII space) 

OxCB 

0x20 

32 

Padding (ASCII space) 


Table 115 Monitor Serial Number Block 
A.2.18 Residual Byte Padding and Check Sum 

CTA-861 requires that residual addresses contain padding. In this case, 0x00 is used as padding. 
Address OxFF should contain a one-byte checksum value such that when all bytes of the entire 128-byte 
block are added, the sum modulus 256 equals 0x00. Table 116 illustrates these requirements. 
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Address 

Hex 

Example Data 

Hex Dec 

OxCC 

OxOO 

0 

OxCD 

0x00 

0 

OxCE 

0x00 

0 

OxCF 

0x00 

0 

OxDO 

0x00 

0 

OxDI 

0x00 

0 

0xD2 

0x00 

0 

0xD3 

0x00 

0 

0xD4 

0x00 

0 

0xD5 

0x00 

0 

0xD6 

0x00 

0 

0xD7 

0x00 

0 

0xD8 

0x00 

0 

0xD9 

0x00 

0 

OxDA 

0x00 

0 

OxDB 

0x00 

0 

OxDC 

0x00 

0 

OxDD 

0x00 

0 

OxDE 

0x00 

0 

OxDF 

0x00 

0 

OxEO 

0x00 

0 

OxEI 

0x00 

0 

0xE2 

0x00 

0 

0xE3 

0x00 

0 

0xE4 

0x00 

0 

0xE5 

0x00 

0 

0xE6 

0x00 

0 

0xE7 

0x00 

0 

0xE8 

0x00 

0 

0xE9 

0x00 

0 

OxEA 

0x00 

0 

OxEB 

0x00 

0 

OxEC 

0x00 

0 

OxED 

0x00 

0 

OxEE 

0x00 

0 

OxEF 

0x00 

0 

OxFO 

0x00 

0 

OxFI 

0x00 

0 

0xF2 

0x00 

0 

0xF3 

0x00 

0 

0xF4 

0x00 

0 

0xF5 

0x00 

0 

0xF6 

0x00 

0 

0xF7 

0x00 

0 

0xF8 

0x00 

0 

0xF9 

0x00 

0 

OxFA 

0x00 

0 

OxFB 

0x00 

0 

OxFC 

0x00 

0 

OxFD 

0x00 

0 

OxFE 

0x00 

0 

OxFF 

0x84 

132 


Description 


1 st padding byte 


Additional padding bytes 


Remarks 



Last padding byte 


Checksum 


Block 1 sum (address 0x80~0xFF) = 0x0E7C 


Table 116 Residual Byte Stuffing and Check Sum Block 
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A.2.19 Hot Plugging Sequence 

An important element to proper interpretation of EDID is “Hot Plugging”. The following presents a 
recommendation for achieving consistent results during a Hot Plugging event. 

DVI 1.0 defines a Hot Plug Detect (HPD) signal function that indicates to the Source whether a display is 
connected. HPD is designed to be powered by the DDC + 5V coming from the Source, and to be 
independent of whether the monitor is powered or not. In this way, a Source can detect the monitor and 
read its characteristics from EDID without the monitor being powered. On a PC, this feature allows the 
system to load the correct display configuration without delaying the boot process. 

In short, in this context, HPD serves as an indication that the EDID is available to be read, however HPD 
may also have alternative uses. It does not imply any other state of readiness. The relevant definitions 
from the DVI 1.0 specification are: 

a) Section 2.6: Hot Plug Detect (HPD) - Signal is driven by monitor to enable the system to identify the 
presence of a monitor. 

b) Section 2.2.9.2: The monitor is required to provide a voltage of greater than +2.4V on the Hot Plug 
Detect (HPD) pin of the connector only when the EDID data structure is available to be read by the 
Source. 

Implementation Note: As an example for hot plug support, a simple monitor implementation of HPD 
support could be a pull up resistor to the EDID power supply. After HPD goes active, the Source is only 
expected to read EDID and determine that a valid display mode is available and supported. 

NOTE—Whenever the EDID information in a device changes for any reason (e.g., if the EDID 
was updated, or is capable of dynamically changing its information content), the receiving device 
pulses HPD low for at least 100ms. This recommendation follows from the HDCP repeater 
implementation requirement that HDCP repeaters pulse HPD low for at least 100ms to indicate 
the connection of a new device or disconnection of an existing one. 
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A.2.20 InfoFrame Data Block 

An example InfoFrame Data Block is shown in Table 117. It is defined as an 11-byte data structure 
located in the CTA Data Block Collection. The first byte is a tag used to identify the data block as 
extended along with its payload length. The second byte identifies the extended data block as an 
InfoFrame Data Block. The tag/length and extended type bytes are followed by an InfoFrame Processing 
Descriptor, which indicates that up to 4 VSIFs may be received simultaneously. Short InfoFrame 
Descriptors follow the InfoFrame Processing Descriptor in order of priority. In this example, support for 
THX Auxiliary VSIF, NTSC VBI, and SPD InfoFrames are indicated. The highest priority is the THX 
Auxiliary VSIF, while the lowest is the SPD InfoFrame. By convention, Interface VSIF remains a higher 
priority than the THX VSIF, however. The Short InfoFrame Descriptors are described in Section 7.5.9. 


Address 

Hex 

Example Data 

Hex Dec 

Description 

Remarks 

OxBA 

OxEA 

234 

Start InfoFrame data 
block. Indicates Extended 
Tag Code and length of 
following data block 
payload 

OxEA = Extended type block (code = 7) and 
ten bytes of data payload 

OxBB 

0x20 

32 

InfoFrame Data Block. 
Extended Tag Code 

0x20 = InfoFrame Data Block Extension Tag 

OxBC 

0x00 

0 

InfoFrame Processing 
Descriptor 

Zero bytes of extended description - 
therefore only header present. 

OxBD 

0x03 

3 

3 additional VSIFs that can be received 
in addition to the first for a total of 4 

OxBE 

0x21 

33 

Short Vendor-Specific 
InfoFrame Descriptor 

Supports the indicated VSIF InfoFrame 
(code=1) and one extended VSIF 
description byte - therefore header plus one 
byte of extended description. 

OxBF 

OxFA 

250 

THX Identifier = 0x0012FA (The big-endian 
THX's 24-bit OUI Registration Identifier 

0x0012FA is placed into the EDID in little- 
endian order.) 

OxCO 

0x12 

18 

OxCI 

0x00 

0 

0xC2 

0x01 

1 

THX’s Extended VSIF Description 

0xC3 

0x06 

6 

Short InfoFrame 

Descriptor 

Supports NTSC VBI InfoFrame (code=6), 

Zero bytes of extended description - 
therefore only header present. 

0xC4 

0x03 

3 

Short InfoFrame 

Descriptor 

Supports SPD InfoFrame (code=3) 

Zero bytes of extended description - 
therefore only header present. 


Table 117 InfoFrame Data Block (Example) 
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A.3 Complete Example EDID Table (Informative) 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x00 

0x00 

0 

Block Zero Header 


Fixed Value 

0x01 

OxFF 

255 

0x02 

OxFF 

255 

0x03 

OxFF 

255 

0x04 

OxFF 

255 

0x05 

OxFF 

255 

0x06 

OxFF 

255 

0x07 

0x00 

0 

0x08 

OxOC 

12 

Vendor / Product ID 

Manufacturer Name 

CTA 

0x09 

OxAl 

161 

OxOA 

0x00 

00 

Product Code 

Used to differentiate 
between different models 
from the same 
manufacturer. 

0x0 B 

0x00 

0 

OxOC 

0x00 

00 

Serial Number 

Optional. 

The serial number can also 
be stored in a separate 
descriptor block 

0x0 D 

0x00 

00 

0x0 E 

0x00 

00 

0x0 F 

0x00 

00 

0x10 

0x00 

0 

Week of Manufacture 

Optional. 

If this field is unused, the 
value should be set to 0. 

0x11 

OxOC 

12 

Year of Manufacture 

Year 2002 

0x12 

0x01 

1 

EDID Structure Version / 
Revision 

Version # 

1 

0x13 

0x03 

3 

Revision # 

3 

0x14 

0x80 

128 

Basic Display Parameters / 
Features 

Video Input Definition 

Digital, VESA DFP1X : not 
compatible 

0x15 

0x50 

80 

Max. Horizontal Image 

Size in cm 

Optional. 

The system should not make 
any assumption regarding 
display size 

0x16 

0x2 D 

45 

Max. Vertical Image Size 
in cm 

Optional. 

See above. 

0x17 

0x78 

120 

Gamma: (gamma x 100)- 
100 = value 

Example is: (gamma = 2.2) 
(2.2 x 100)-100 = 120 

0x18 

OxOA 

10 

Feature Support 

OxOA denotes: 

RGB color Display type, 
preferred timing: first 
detailed timing block. GTF 
timing: not supported. 

Standby mode: not 
supported, suspend mode: 
not supported, active off: not 
supported 


Table 118 Complete EDID Example 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x19 

0x0 D 

13 

Color Characteristics 

Red/Green Low Bits 


0x1 A 

0xC9 

201 

Blue/White Low Bits 


0x1 B 

OxAO 

160 

Red-x 

0.625 

0x1 C 

0x57 

87 

Red-y 

0.340 

0x1 D 

0x47 

71 

Green-x 

0.280 

0x1 E 

0x98 

152 

Green-y 

0.595 

0x1 F 

0x27 

39 

Blue-x 

0.155 

0x20 

0x12 

18 

Blue-y 

0.070 

0x21 

0x48 

72 

White-x 

0.283 

0x22 

0x4C 

76 

White-y 

0.298 

0x23 

0x20 

32 

Established Timings 

Timing 1 

640x480 @60Hz 

0x24 

0x00 

0 

Timing 2 

None 

0x25 

0x00 

0 

Manufacturer's Reserved 

Timing 

None 

0x26 

0x01 

1 

Standard Timing 

ID #1-8 

Standard Timing ID #1 

PC Applications 

0x27 

0x01 

1 

0x28 

0x01 

1 

Standard Timing ID #2 

PC Applications 

0x29 

0x01 

1 

0x2A 

0x01 

1 

Standard Timing ID #3 

PC Applications 

0x2 B 

0x01 

1 

0x2C 

0x01 

1 

Standard Timing ID #4 

PC Applications 

0x2 D 

0x01 

1 

0x2 E 

0x01 

1 

Standard Timing ID #5 

PC Applications 

0x2 F 

0x01 

1 

0x30 

0x01 

1 

Standard Timing ID #6 

PC Applications 

0x31 

0x01 

1 

0x32 

0x01 

1 

Standard Timing ID #7 

PC Applications 

0x33 

0x01 

1 

0x34 

0x01 

1 

Standard Timing ID #8 

PC Applications 

0x35 

0x01 

1 

0x36 

0x01 

1 

First Detailed Timing 
Descriptor (Preferred) 

Pixel Clock 

74.25 MHz 

0x37 

0x1 D 

29 

0x38 

0x80 

128 

H Active 

1920 pixels 

0x39 

0x18 

24 

H Blanking 

280 pixels 

0x3A 

0x71 

113 

■ mii'iin inline 


0x3 B 

0x1 C 

28 

V Active 

540 lines 

0x3C 

0x16 

22 

V Blanking 

22 lines 

0x3 D 

0x20 

32 

V Active: V Blanking 


0x3 E 

0x58 

88 

H Sync Offset 

88 pixels 

0x3 F 

0x2C 

44 

H Sync Pulse Width 

44 pixels 

0x40 

0x25 

37 

VS Offset: VS Pulse 

Width 

2 lines, 5 lines 

0x41 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0x42 

0x20 

32 

H Image Size 

800 mm 

0x43 

0xC2 

194 

V Image Size 

450 mm 

0x44 

0x31 

49 



0x45 

0x00 

0 

H Border 

0 pixels 

0x46 

0x00 

0 

V Border 

0 lines 

0x47 

0x9 E 

158 

Flags 

Interlaced, normal display no 
stereo, digital separate, 

Vsync polarity is positive, 
Hsync polarity is positive 
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Address 

Hex 

Example Data 
Hex Dec 

0x48 

0x8C 

140 

0x49 

OxOA 

10 

0x4A 

OxDO 

208 

0x4 B 

0x8A 

138 

0x4C 

0x20 

32 

0x4 D 

OxEO 

224 

0x4 E 

0x2 D 

45 

0x4 F 

0x10 

16 

0x50 

0x10 

16 

0x51 

0x3 E 

62 

0x52 

0x96 

150 

0x53 

0x00 

0 

0x54 

0x58 

88 

0x55 

0xC2 

194 

0x56 

0x21 

33 

0x57 

0x00 

0 

0x58 

0x00 

0 

0x59 

0x18 

24 

0x5A 

0x00 

0 

0x5 B 

0x00 

0 

0x5C 

0x00 

0 

0x5 D 

OxFC 

252 

0x5 E 

0x00 

0 

0x5 F 

0x4 D 

77 

0x60 

0x59 

89 

0x61 

0x20 

32 

0x62 

0x48 

72 

0x63 

0x44 

68 

0x64 

0x54 

84 

0x65 

0x56 

86 

0x66 

OxOA 

10 

0x67 

0x20 

32 

0x68 

0x20 

32 

0x69 

0x20 

32 

0x6A 

0x20 

32 

0x6 B 

0x20 

32 


Name of Block 


Second Detailed Timing 
Descriptor 


Monitor Descriptor 
Currently Mandatory 
(Monitor Name) 


Description 


Pixel Clock 


H Active 


H Blanking_ 


H Active: H Blanking 


V Active 


V Blanking 


V Active: V Blanking 


H Sync Offset 


H Sync Pulse Width 


VS Offset: VS Pulse 
Width 


HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


V Image Size 


H&V Image Size 


H Border 


V Border 


Flags 


Flag (Reserved) 


Data Type Tag 


m 


Remarks 


720 pixels 


138 pixels 


480 lines 


45 lines 


16 pixels 


62 pixels 


9 lines, 6 lines 



0 pixels 


0 lines 


non-interlaced, normal 
display no stereo, digital 
separate, V. and H. sync 
polarity is negative_ 



Monitor name type 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x6C 

0x00 

0 

Second Monitor Descriptor 
Currently Mandatory 
(range limits, binary coded) 

Flag 


0x6 D 

0x00 

0 

0x6 E 

0x00 

0 

Flag (Reserved) 


0x6 F 

OxFD 

253 

Data Type Tag 

Monitor Range limits, binary 
coded, mandatory block 

0x70 

0x00 

0 

sum* 


0x71 

0x3 B 

59 

Min Vertical Rate in Hz 

59 HZ 

0x72 

0x3 D 

61 

Max Vertical Rate in Hz 

61 Hz 

0x73 

0x0 F 

15 

Min Horizontal Rate in 
kHz 

15 kHz 

0x74 

0x2 E 

46 

Max Horizontal Rate in 
kHz 

46 kHz 

0x75 

0x08 

8 

Max Supported pixel 
clock rate in MHz/10 

80 MHz 

0x76 

0x00 

0 

■iiiiijH 

No secondary timing formula 
supported 

0x77 

OxOA 

10 

Fixed 


0x78 

0x20 

32 

Fixed 


0x79 

0x20 

32 

Fixed 


0x7A 

0x20 

32 

Fixed 


0x7 B 

0x20 

32 

Fixed 


0x7C 

0x20 

32 

Fixed 


0x7 D 

0x20 

32 

Fixed 


0x7 E 

0x01 

1 

Extension Flag 

Number of 128 bytes 
blocks to follow 


0x7 F 

0xC3 

195 

Checksum 

Block 0 sum = 0x1 B3D 

0x80 

0x02 

2 

CTA Extension Header 

Tag 

Block One 

0x81 

0x01 

1 

0x01 by 861 

Revision Number 

0x82 

0x04 

m 

0x04, no data in 

Reserved 

Byte Offset 

0x83 

0x00 

0 

0x00 by 861 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x84 

0x01 

1 

Third Detailed Timing 
Descriptor 

Pixel Clock 

74.25 MHz 

0x85 

0x1 D 

29 

0x86 

0x00 

0 

H Active 

1280 pixels 

0x87 

0x72 

114 

H Blanking 

370 pixels 

0x88 

0x51 

81 

H Active: H Blanking 


0x89 

OxDO 

208 

V Active 

720 lines 

0x8A 

0x1 E 

30 

V Blanking 

30 lines 

0x8 B 

0x20 

32 

V Active: V Blanking 


0x8C 

0x6 E 

110 

H Sync Offset 

110 pixels 

0x8 D 

0x28 

40 

H Sync Pulse Width 

40 pixels 

0x8 E 

0x55 

85 

VS Offset: VS Pulse 

Width 


0x8 F 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0x90 

0x20 

32 

kUuuAi 

800 mm 

0x91 

0xC2 

194 

V Image Size 

450 mm 

0x92 

0x31 

49 

H&V Image Size 


0x93 

0x00 

0 

H Border 

0 pixels 

0x94 

0x00 

0 

V Border 

0 lines 

0x95 

0x1 E 

30 

Flags 

Non-interlaced, normal 
display no stereo, digital 
separate, H and V sync 
polarity is positive 

0x96 

0x8C 

140 

Fourth Detailed Timing 
Descriptor 

Pixel Clock 

27 MHz 

0x97 

OxOA 

10 

0x98 

OxAO 

160 

H Active 

1440 pixels 

0x99 

0x14 

20 

H Blanking 

276 pixels 

0x9A 

0x51 

81 

■ mii'iin lining 


0x9 B 

OxFO 

240 

V Active 

240 lines 

0x9C 

0x16 

22 

V Blanking 

22 lines 

0x9 D 

0x00 

0 

V Active: V Blanking 


0x9 E 

0x26 

38 

H Sync Offset 

38 pixels 

0x9 F 

0x7C 

124 

H Sync Pulse Width 

124 pixels 

OxAO 

0x43 

67 

VS Offset: VS Pulse 

Width 


OxAl 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0xA2 

0x58 

88 

H Image Size 

600 mm 

0xA3 

0xC2 

194 

V Image Size 

450 mm 

0xA4 

0x21 

33 

H&V Image Size 


0xA5 

0x00 

0 

H Border 

0 pixels 

0xA6 

0x00 

0 

V Border 

0 lines 

0xA7 

0x98 

152 

Flags 

interlaced, normal display no 
stereo, digital separate, V. 
and H. sync polarity is 
negative, 
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CTA-861-G 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0xA8 

OxOO 

0 

Descriptor Defined by 
Manufacturer 

Flag 


0xA9 

0x00 

0 



OxAA 

0x00 

0 

Reserved 


OxAB 

0x01 

1 

Data Type 0x01-OxOF 


OxAC 

0x00 

0 

Flag 


OxAD 

0x52 

82 

‘R’ 


OxAE 

0x45 

69 

‘E’ 


OxAF 

0x56 

86 

‘V’ 


OxBO 

0x31 

49 

‘1’ 


OxBI 

0x2 E 

46 



0xB2 

0x30 

48 

‘0’ 


0xB3 

0x30 

48 

‘0’ 


0xB4 

OxOA 

10 



0xB5 

0x00 

0 



0xB6 

0x00 

0 



0xB7 

0x00 

0 



0xB8 

0x00 

0 



0xB9 

0x00 

0 



OxBA 

0x00 

0 

Monitor Serial Number 
(ASCII, 13 bytes max) 



OxBB 

0x00 

0 



OxBC 

0x00 

0 



OxBD 

OxFF 

255 

Serial Number Tag 


OxBE 

0x00 

0 



OxBF 

0x39 

57 

‘9’ 


OxCO 

0x39 

57 

‘9’ 


OxCI 

0x46 

70 



0xC2 

0x43 

67 

‘C’ 


0xC3 

0x35 

53 

‘5’ 


0xC4 

0x30 

48 

‘0’ 


0xC5 

0x30 

48 

‘0’ 


0xC6 

0x30 

48 

‘0’ 


0xC7 

0x31 

49 

‘1’ 


0xC8 

OxOA 

10 



0xC9 

0x20 

32 



OxCA 

0x20 

32 



OxCB 

0x20 

32 
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CTA-861-G 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

OxCC 

OxOO 

0 

Residual Byte Padding 



OxCD 

0x00 

0 




OxCE 

0x00 

0 




OxCF 

0x00 

0 




OxDO 

0x00 

0 




OxDI 

0x00 

0 




0xD2 

0x00 

0 




0xD3 

0x00 

0 




0xD4 

0x00 

0 




0xD5 

0x00 

0 




0xD6 

0x00 

0 




0xD7 

0x00 

0 




0xD8 

0x00 

0 




0xD9 

0x00 

0 




OxDA 

0x00 

0 




OxDB 

0x00 

0 




OxDC 

0x00 

0 




OxDD 

0x00 

0 




OxDE 

0x00 

0 




OxDF 

0x00 

0 




OxEO 

0x00 

0 




OxEI 

0x00 

0 




0xE2 

0x00 

0 




0xE3 

0x00 

0 




0xE4 

0x00 

0 




0xE5 

0x00 

0 




0xE6 

0x00 

0 




0xE7 

0x00 

0 




0xE8 

0x00 

0 




0xE9 

0x00 

0 




OxEA 

0x00 

0 




OxEB 

0x00 

0 




OxEC 

0x00 

0 




OxED 

0x00 

0 




OxEE 

0x00 

0 




OxEF 

0x00 

0 




OxFO 

0x00 

0 




OxFI 

0x00 

0 




0xF2 

0x00 

0 




0xF3 

0x00 

0 




0xF4 

0x00 

0 




0xF5 

0x00 

0 




0xF6 

0x00 

0 




0xF7 

0x00 

0 




0xF8 

0x00 

0 




0xF9 

0x00 

0 




OxFA 

0x00 

0 




OxFB 

0x00 

0 




OxFC 

0x00 

0 




OxFD 

0x00 

0 




OxFE 

0x00 

0 




OxFF 

0x84 

132 

Checksum 


Block 1 sum = 0x0E7C 
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CTA-861-G 


A.4 Example EDID Detailed Timing Descriptors 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x01 


Pixel Clock = 74.25 MHz 

0x37 

OxlD 


0x38 

Horizontal Active Pixels (lower 8 bits) 

0x00 


hor. Active Pixels = 1280 = 0x500 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x72 


Mmsssms^^mssm 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x51 



0x3B 

Vertical Active Lines, lower 8 bits 

OxDO 


vert. Active Lines = 720 = 0x2D0 

0x3C 

Vertical Blanking Lines, lower 8 bits 

OxlE 


vert. Blanking Lines = 30 = OxlE 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x6E 


offset =110 pixels = 0x6E 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x28 


width = 40 pixels = 0x28 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x55 


vert sync, offset = 5 lines 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x0 


Shall be 0 

0x46 

Vertical Border (lines) 

0x0 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

OxlE 

00011110 

Flag = non- interlaced; non-stereo; 
digital separate; positive V sync; 
positive H sync 


Table 119 Example EDID Detailed Timing Descriptor for 1280x720p (60 Hz, 16:9) 
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Byte# 

(Hex) 

Function 

mSSm 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 



Pixel Clock = 74.25 MHz 

0x37 

0x1 D 


0x38 

Horizontal Active Pixels (lower 8 bits) 

0x80 


hor. Active Pixels = 1920 = 0x780 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x18 


hor. blanking pixels = 280 = 0x118 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x71 



0x3B 

Vertical Active Lines, lower 8 bits 

0x1 C 


vert. Active Lines = 540 = 0x21 C 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x16 


vert. Blanking Lines = 22 = 0x16 19 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x58 


offset = 88 pixels = 0x58 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x2C 


width = 44 pixels = 0x2C 

0x40 

Vert, sync offset; Vert, sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

0x25 


vert, sync offset = 2 lines 20 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 

0x2C4 21 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8 E 


Vert. Image Size = 398 mm = 0x18E 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 


0x00 


Shall be 0 1 

0x47 

Flags (bit 7 = interlaced; bit 5,6 = normal 
display; bit 1,2, 3,4 = sync description; bit 

0 = do not care) 

0x9 E 

10011110 

Flag = interlaced; non-stereo; digital 
separate; positive V sync; positive H 
sync 


Table 120 Example EDID Detailed Timing Descriptor for 1920x1080i (60 Hz, 16:9) 


19 For interlaced display: Field 1 vertical blanking = Vertical Blanking Lines. Field 2 vertical blanking = Vertical 
Blanking Lines + 1 Blanking Line. 

20 For interlaced display: Field 1 vertical offset = Vertical Sync Offset. Field 2 vertical offset = Vertical Sync Offset + 
0.5 lines. 

21 Image size is display dependent. Ratio of Horizontal Image Size to Vertical Image Size shall be 16:9 or 4:3. 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxDO 


hor. Active Pixels = 720 = 0x2D0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x8A 


hor. blanking pixels = 138 = 0x8A 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3B 

Vertical Active Lines, lower 8 bits 

OxEO 


vert. Active Lines = 480 = 0x1 E0 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x2D 


vert. Blanking Lines = 45 = 0x2D 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x10 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x10 


offset = 16 pixels = 0x10 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x3E 


width = 62 pixels = 0x3E 

0x40 

Vert, sync offset; Vert, sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x9 6 


vert, sync offset = 9 lines 
vert, sync width = 6 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0x13 


Hor. Image size = 531 mm = 0x213 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 0x18E 
(4:3 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x18 

00011000 

Flag = non-interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 121 Example EDID Detailed Timing Descriptor for 720x480p (59.94 Hz, 4:3) 
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Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxDO 


hor. Active Pixels = 720 = 0x2D0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x8A 



0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3B 

Vertical Active Lines, lower 8 bits 

OxEO 


vert. Active Lines = 480 = 0x1 E0 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x2D 


vert. Blanking Lines = 45 = 0x2D 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x10 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x10 


offset = 16 pixels = 0x10 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x3E 


width = 62 pixels = 0x3E 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

0x96 


vert sync, offset = 9 lines 
vert, sync width = 6 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 

0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (16:9 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x18 

00011000 

Flag = non-interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 122 Example EDID Detailed Timing Descriptor for 720x480p (59.94Hz, 16:9) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxAO 


hor. Active Pixels = 1440 = 0x5A0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x14 



0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x51 



0x3B 

Vertical Active Lines, lower 8 bits 

OxFO 


vert. Active Lines = 240 = OxFO 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x16 


vert. Blanking Lines = 22 = 0x16 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x00 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x2 6 


offset = 38 pixels = 0x26 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x7C 


width = 124 pixels = 0x7C 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x43 


vert sync, offset = 4 lines 
vert, sync width = 3 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0x13 


Hor. Image size = 531 mm = 

0x213 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (4:3 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x98 

10011000 

Flag = interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 123 Example EDID Detailed Timing Descriptor for 720x480i (59.94Hz, 4:3) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxAO 


hor. Active Pixels = 1440 = 0x5A0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x14 


hor. blanking pixels = 276 = 0x114 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x51 



0x3B 

Vertical Active Lines, lower 8 bits 

OxFO 


vert. Active Lines = 240 = OxFO i 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x16 


vert. Blanking Lines = 22 = 0x16 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x00 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x26 


offset = 38 pixels = 0x26 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x7C 


width = 124 pixels = 0x7C 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x43 


vert sync, offset = 4 lines 
vert, sync width = 3 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 

0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (16:9 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x98 

10011000 

Flag = interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 124 Example EDID Detailed Timing Descriptor for 720x480i (59.94Hz, 16:9) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x01 


Pixel Clock = 74.25 MHz 

0x37 

OxlD 


0x38 

Horizontal Active Pixels (lower 8 bits) 

0x00 


hor. Active Pixels = 1280 = 0x500 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

OxBC 


hor. blanking pixels = 700 = 0x2BC 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x52 



0x3B 

Vertical Active Lines, lower 8 bits 

OxDO 


vert. Active Lines = 720 = 0x2D0 j 

0x3C 

Vertical Blanking Lines, lower 8 bits 

OxlE 


vert. Blanking Lines = 30 = OxlE 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0xB8 


offset = 440 pixels = 0x1 B8 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x28 


width = 40 pixels = 0x28 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x55 


vert sync, offset = 5 lines 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x40 

01000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

OxlE 

00011110 

Flag = non- interlaced; non-stereo; 
digital separate; positive V sync; 
positive H sync 


Table 125 Example EDID Detailed Timing Descriptor for 1280x720p (50 Hz, 16:9) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x01 


Pixel Clock = 74.25 MHz 

0x37 

OxlD 


0x38 

Horizontal Active Pixels (lower 8 bits) 

0x80 


Hor. Active Pixels = 1920 = 0x780 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

OxDO 


hor. blanking pixels = 720 = 0x2D0 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 

0x72 



0x3B 

Vertical Active Lines, lower 8 bits 

OxlC 


vert. Active Lines = 540 = 0x21 C i 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x16 


vert. Blanking Lines = 22 = 0x16 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x10 


offset = 528 pixels = 0x210 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x2C 


width = 44 pixels = 0x2C 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x25 


vert sync, offset = 2 lines 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x80 

10000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 0x18E 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = interlaced; bit 5,6 = normal 
display; bit 1,2, 3,4 = sync description; 
bit 0 = do not care) 

0x9E 

10011110 

Flag = interlaced; non-stereo; digital 
separate; positive V sync; positive H 
sync 


Table 126 Example EDID Detailed Timing Descriptor for 1920x1080i (50 Hz, 16:9) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxDO 


hor. Active Pixels = 720 = 0x2D0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x90 


—E— EH»EM 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3B 

Vertical Active Lines, lower 8 bits 

0x40 


vert. Active Lines = 576 = 0x240 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x31 


vert. Blanking Lines = 49 = 0x31 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

OxOC 


offset = 12 pixels = OxOC 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x40 


Width = 64 pixels = 0x40 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x55 


vert sync, offset = 5 lines 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0x13 


Hor. Image size = 531 mm = 

0x213 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (4:3 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x18 

00011000 

Flag = non-interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 127 Example EDID Detailed Timing Descriptor for 720x576p (50 Hz, 4:3) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxDO 


hor. Active Pixels = 720 = 0x2D0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x90 


hor. blanking pixels = 144 = 0x90 

0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3B 

Vertical Active Lines, lower 8 bits 

0x40 


vert. Active Lines = 576 = 0x240 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x31 


vert. Blanking Lines = 49 = 0x31 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x20 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

OxOC 


offset = 12 pixels = OxOC 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x40 


width = 64 pixels = 0x40 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x55 


vert sync, offset = 5 lines 
vert, sync width = 5 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 0x18E 
(16:9 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x18 

00011000 

Flag = non-interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 128 Example EDID Detailed Timing Descriptor for 720x576p (50 Hz, 16:9) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxAO 


hor. Active Pixels = 1440 = 0x5A0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x20 



0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x51 



0x3B 

Vertical Active Lines, lower 8 bits 

0x20 


vert. Active Lines = 288 = 0x120 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x18 


vert. Blanking Lines = 24 = 0x18 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x10 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x18 


offset = 24 pixels = 0x18 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x7E 


Width = 126 pixels = 0x7C 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x23 


vert sync, offset = 2 lines 
vert, sync width = 3 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0x13 


Hor. Image size = 531 mm = 

0x213 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (4:3 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x98 

10011000 

Flag = interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 129 Example EDID Detailed Timing Descriptor for 720x576i (50 Hz, 4:3) 
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CTA-861-G 


Byte# 

(HEX) 

Function 

Value 

(HEX) 

Value 

(binary) 

Notes 

0x36 

Pixel Clock/10,000 (LSB stored first) 

0x8C 


Pixel Clock = 27.00 MHz 

0x37 

OxOA 


0x38 

Horizontal Active Pixels (lower 8 bits) 

OxAO 


hor. Active Pixels = 1440 = 0x5A0 

0x39 

Horizontal Blanking Pixels (lower 8 bits) 

0x20 



0x3A 

Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x51 



0x3B 

Vertical Active Lines, lower 8 bits 

0x20 


vert. Active Lines = 288 = 0x120 

0x3C 

Vertical Blanking Lines, lower 8 bits 

0x18 


vert. Blanking Lines = 24 = 0x18 

0x3D 

Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x10 



0x3E 

Horizontal sync, offset (pixels) 

(from blanking starts, lower 8 bits) 

0x18 


offset = 24 pixels = 0x18 

0x3F 

Horizontal sync pulse width (pixels) 

(lower 8 bits) 

0x7E 


Width = 126 pixels = 0x7E 

0x40 

Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of 
vertical sync offset) 

(lower nibble = lines, lower 4 bits of 
vertical sync pulse width) 

0x23 


vert sync, offset = 2 lines 
vert, sync width = 3 lines 

0x41 

bits 7,6: upper 2 bits of Hor. sync, offset 
bits 5,4: upper 2 bits of Hor. sync pulse 
width 

bits 3,2: upper 2 bits of vert sync offset 
bits 1,0: upper 2 bits of vert, sync pulse 
width 

0x00 

00000000 


0x42 

Horizontal Image Size (mm, lower 8 bits) 

0xC4 


Hor. Image size = 708 mm = 

0x2C4 

0x43 

Vertical Image Size (mm, lower 8 bits) 

0x8E 


Vert. Image Size = 398 mm = 

0x18E (16:9 in this case). 

0x44 

Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 

(lower nibble = upper 4 bits of vert.) 

0x21 



0x45 

Horizontal Border (pixels) 

0x00 


Shall be 0 

0x46 

Vertical Border (lines) 

0x00 


Shall be 0 

0x47 

Flags (bit 7 = non-interlaced; bit 5,6 = 
normal display; bit 1,2, 3,4 = sync 
description; bit 0 = do not care) 

0x98 

10011000 

Flag = interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 


Table 130 Example EDID Detailed Timing Descriptor for 720x576i (50 Hz, 16:9) 


159 









































































CTA-861-G 


Annex B Application to DV11.0 (Normative) 

All mandatory aspects of DVI 1.0 [4] shall be implemented with the exception of those expressly identified 
as optional or informative when DVI 1.0 is used to implement CTA-861. DVI does not support transport of 
CTA InfoFrames, audio or YCbCr Pixel Data. However, CTA-861 can still be implemented on DVI 1.0 
(with reduced functionality) as explained at the beginning of Section 6. 

The EDID content shall comply with EDID data structure Version 1, Revision 3 [9]. 

All sections in Annex B are normative when DVI 1.0 is used to implement CTA-861 except as otherwise 
noted. 

B.1 Connector and Cable 

The connector used shall be DVI-Digital, Single Link [4]. 

The cable, if supplied with the product, shall be compliant with the DVI specification at maximum pixel 
clock frequency compatible with the product. 

B.2 Digital Content Protection 

High-bandwidth Digital Content Protection (HDCP) version 1.1 [3] or later is available to protect the video 
data carried on a DVI link. 
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CTA-861-G 


Annex C Application to Open LDI (Normative) 

All mandatory aspects of OpenLDI 0.95 [8] shall be implemented with the exception of those expressly 
identified as optional or informative in that standard when OpenLDI 0.95 is used to implement CTA-861. It 
should be noted that at the time of this writing, a version of OpenLDI that supports transport of CTA 
InfoFrames was not available. However, CTA-861 can still be implemented on OpenLDI 0.95 (with 
reduced functionality) as explained in Section 6. 


All sections in this Annex are normative when OpenLDI 0.95 is used to implement CTA-861 except as 
otherwise noted. 

C.1 Open LDI Data and Control Signals 

OpenLDI has two options for display synchronization: 

a) DC Balance Mode: 

b) Non DC Balance Mode: 

In DC Balance mode synchronization is accomplished by transmitting control signals during the Display 
blanking intervals as shown in Figure 8. 
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\ Data 


1 


Blanking 

Time 
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Control 
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Active 

Display 


1 _ 


I 


Pixel 

Data 
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Figure 8 OpenLDI Synchronization 

In the single or dual LVDS bus mode (24 or 48 bit Total), the control signals are transmitted over 7 
transition words on specific output signals during the blanking period as indicated in Table 131. 


Control Signal 

Signal Level 

Output Signal 

Data Pattern 

DE 

High 

CLK1 and CLK2 

1111000 or 1110000 | 

Low 

1111100 or 1100000 

HSYNC 

High 

AO 

1100000 or 1111100 

Low 

1110000 or 1111000 

VSYNC 

High 

A1 

1100000 or 1111100 

Low 

1110000 or 1111000 


Table 131 OpenLDI Control Signals 


C.2 Non DC Balanced Mode 

Control signals are transmitted as part the LVDS serialized data stream. The controls signals are then de¬ 
serialized and regenerated at the receiver outputs to the HDTV. 

C.3 OpenLDI Cabling Information 

An OpenLDI cable assembly shall consist of a cable meeting the requirements of this section with an 
OpenLDI plug on each end or an OpenLDI plug on one end and the other end permanently affixed to the 
display device. Acceptable cables for OpenLDI may use either shielded or unshielded twisted pairs. It is 
up to the manufacturer of the OpenLDI equipment to use the grade and type of cable required to meet 
applicable regulatory requirements. Adherence to CTA-861 does not guarantee regulatory compliance. 

When the OpenLDI is an interface internal to an assembly and not accessible externally, the OpenLDI 
cable may be replaced with any cable or connection means appropriate to the requirements of the 
assembly. 
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C.3.1 Cable Length 

The maximum cable length shall be 10m. 

C.3.2 Number of Signal Conductors 

The OpenLDI cable shall comprise 11 twisted pairs and 10 individual conductors. 

C.3.3 Wire Gauge 

Each conductor in an OpenLDI cable shall be no less than 28AWG. 

C.3.4 Conductor Resistance 

The resistance of a single conductor of an OpenLDI cable shall not exceed 40 when the conductor is of 
the maximum length specified in CTA-861. 

C.3.5 Insulation 

Each conductor in the cable shall be separately insulated. The minimum insulation resistance shall be 
1GQ. 

C.3.6 Shield Requirement 

The OpenLDI cable shall be encompassed by a single shield, surrounding all conductors in the cable. 

The shield shall provide a minimum of 90% coverage. 

For shielded twisted pair cable, each twisted pair shall be shielded individually. Each shield shall provide 
a minimum of 90% coverage. 

C.3.7 Single Twisted Pair Transmission Skew 

The differential time of transmission (single pair transmission skew) of a pulse through a single differential 
pair in an OpenLDI cable shall not exceed 300ps. 

C.3.8 Multiple Twisted Pair Transmission Skew 

The differential time of transmission (pair to pair transmission skew) of a pulse through any two differential 
pairs in an OpenLDI cable shall not exceed 1 bit time. 

C.3.9 USB Cable Requirements 

The conductors used for transmission of USB signals on the OpenLDI cable shall meet the requirements 
stated in the Universal Serial Bus Specification, Version 1.0, January 15, 1996. 

C.3.10 DDC Cable Requirements 

The conductors used for transmission of DDC signals on the OpenLDI cable shall meet the requirements 
stated in the VESA Display Data Channel Command Interface (DDC/CI) Standard, Version 1, August 14, 
1998 [10]. 

More information on the connector is available in Section 7.2 of the OpenLDI specification [8]. 
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Annex D Application to HDMI (Informative) 

D.1 InfoPackets 

HDMI carries each InfoFrame in its own HDMI packet. The HDMI packet type for an InfoFrame packet is 
equal to 0x80+lnfoFrame Type, therefore, only InfoFrames with Types less than 0x80 may be transmitted. 
Including Type, Version, and Length fields, InfoFrames of at most 30 bytes are supported. A checksum is 
present in each InfoFrame. 

Refer to the HDMI Specification for more detail on the packetization of InfoFrames. 

D.2 EDID 

A Sink using an HDMI input shall contain an EDID consisting of a single E-EDID Version 1, Revision 3 
block and at least one CTA Extension version 3. 

A Sink that supports either type of YCbCr Pixel Data (4:2:2 or 4:4:4) shall support both types and 
therefore shall set both bits 4 and 5 of byte 3 of all CTA EDID Extensions within the EDID. A Sink that 
does not support YCbCr Pixel Data shall have both bits 4 and 5 clear. See D.6 for an example. 

If the Sink supports any type of digital audio on this interface, then it shall also support Basic Audio and 
shall indicate this by setting the Basic Audio bit (bit 6). 

Bit 7 of byte 3 shall be set if the Sink underscans IT Video Formats by default. 

D.3 Audio 

HDMI [71] is capable of supporting a variety of audio formats, including uncompressed digital audio (L- 
PCM), in an IEC 60958-3 [12] compliant stream at up to 8 channels, up to 192 kHz and up to 24 
bits/sample, and compressed digital audio, in an IEC 61937-2 [93] compliant stream, up to 192 kHz. 

HDMI [71] relies on the defined audio discovery mechanisms present in the CTA EDID Extension Version 

3. 

The Audio InfoFrame, the IEC 60958-3 [12] “Channel Status” bits, and the IEC 61937-2 [93] “Burst Info” 
bits are used to describe the transmitted audio stream. The Audio InfoFrame CT (coding type), SS 
(sample size) and SF (sample frequency) fields are required to be 0 (“Refer to Stream Header”) to avoid 
redundancy with the same data already contained within the IEC 60958-3 [12] stream data. 

D.4 HDCP 

High-bandwidth Digital Content Protection (HDCP) version 1.1 [3] or later is available to protect the audio 
and video data carried on an HDMI link. 

D.5 Additional Information 

HDMI information is available from HDMI Licensing (see Section 2.1.2.2). 

HDCP information is available from Digital-CP, LLC (see Section 2.1.1.2). 

D.6 Example EDID Using Elements of CTA Block Tag Extension (Applicable to HDMI) 

Table 137 contains an example implementation of EDID utilizing elements of the CTA Block Tag 
Extension that were not addressed in Annex A. These elements are Short Video Descriptors, Audio 
Descriptors, Speaker Allocation Block, and a Vendor-Specific Data Block. This example is applicable to 
HDMI implementations. Elements of the Example EDID are addressed individually, in the following 
subsections. 

D.6.1 First Monitor Descriptor (Monitor Name) and Second Monitor Descriptor (Monitor Range 
Limits) 

Although Annex A requires that two of the four 18-byte detailed timing descriptors be a Monitor Name 
Descriptor and a Monitor Descriptor, it is possible that implementations designed for Personal Computers 
(e.g., multimedia applications), may contain a different set of data. For that reason, Sources adhering to 
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CTA-861 should be designed without dependency upon specific data within these blocks that prevent 
collection and interpretation of subsequent data blocks. 

D.6.2 Extension Flag and Checksum 

The Extension Flag and Checksum are defined the same as in A.2.11. 

D.6.3 CTA Extension Header (Block 1) 

The CTA Extension Header is a four-data bytes located in address range 0x80 through 0x83. The first 
byte is the tag used to identify the extension. The number assigned by VESA to this tag is 0x02. 

Following the CTA Extension Tag is the Revision Number location. In this example, the Revision Number 
is set to 0x03. Please note that all Revision numbers are backward compatible. Sources should not have 
a dependency upon Revision Numbers. 

Table 132 contains data based upon the tables presented in this Annex. In this example, the CTA 
Extension Tag is located at address 0x80 followed by Revision Number, Byte Number Offset, and 
Reserved (i.e., 0x00). The data is set as prescribed by CTA-861. 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x80 

0x02 

2 

CTA Extension Header 

Tag 

Block One 

0x81 

0x03 

3 


Revision Number 

Start of CTA Block Tag 
Extension 

0x82 

0x1 A 

26 



Byte Offset 

0x83 

0x71 

113 


Global Declarations 

DTV, YCbCr (4:4:4), YCbCr 
(4:2:2) 


Table 132 CTA Extension Header (Block 1) 

D.6.4 CTA Data Block Collection 

The CTA Data Block Collection is within the CTA Extension Block and declares CTA Short Video 
Descriptors, Audio capabilities, Speaker configuration, a Vendor-Specific Block that requires an Identifier 
code, and a Vendor-Specific Payload bock that is used to carry additional and optional data. As noted in 
Section 7.5, the Data Block ordering sequence is not constrained and various combinations are possible; 
and therefore, the examples provided herein are based upon one possible combination. 

D.6.5 Video Data Block 

The purpose of this block is for listing Short Video Descriptors (SVDs). Short Video Descriptors are used 
to declare Video Formats with one byte as contrasted with 18 bytes for Detailed Timing Descriptors, 
which is useful in economizing memory space. The preferred SVD is listed first. Subsequent SVDs are of 
decreasing preference. 

As defined in Table 54 (General Tag Format), the first byte is used to signify a Video Tag Code and 
Payload Length. Bits 5 to 7 designate the Tag Code and payload length is defined by bits 0 to 4. 

The payload byte structure is defined in Table 58. Bits 0 through 6 are used for a Video Identification 
Codes as defined in Table 3; and bit 7 (MSB) is a marker bit called “Native.” If bit 7 is set to T, the format 
is a “Native Video Format” (see Section 2.2), and if set to ‘zero’ the format is not “Native.” 

In the example, as shown in Table 133, bits 5 through 7 located in address 0x84 are set to Tag Code 2 
(0x04) designating a Video Data Block; and bits 0 to 4 is set to 0x7 indicating seven bytes of data 
payload. Addresses 0x85 through 0x8B contain one discrete Short Video Descriptor code per byte. 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x84 

0x47 

71 

Video Data 
Block 

Start of data block collection. 
Includes Tag Code and length 
of following data block payload 

0x47 = Video Block (code = 2) 
and seven bytes of data payload 

0x85 

0x85 

132 


1 st Short Video Descriptor 

1920x1080i @ 59.94/60 Hz 16:9 
Native Mode 

0x86 

0x02 

2 


2 nd Short Video Descriptor 

720x480p 59.94/60 Hz 4:3 

0x87 

0x03 

3 


3 rd Short Video Descriptor 

720x480p 59.94/60 Hz 16:9 

0x88 

0x04 

4 


4 th Short Video Descriptor 

1280x720p 59.94/60 Hz 16:9 

0x89 

0x06 

6 


5 th Short Video Descriptor 

720(1440)x480i 59.94/60 Hz 4:3 

0x8A 

0x07 

7 


6 th Short Video Descriptor 

720(1440)x480i 59.94/60 Hz 16:9 

0x8 B 

0x01 

1 


7 th Short Video Descriptor 

640x480p 59.94/60 Hz 4:3 


Table 133 Video Data Block 


D.6.6 CTA Audio Block 

The Audio Data Block is used to declare format, frequency, and bit-rate. The structure of this table is 
defined in Table 53 with subsequent tables addressing the General Tag Format, Short Audio Descriptors, 
and Audio Format Codes. Multiple, Short Audio Descriptors may be used in this block. 

The first byte in this block is the General Format Tag and is the same structure as the Video Data Block 
as defined in Table 54, General Tag Format. The Tag Code occupies bits 5 and 7; and Payload Length is 
placed in bits 0 through 4. Audio Tag Codes are listed in Table 34, Audio Format Codes. Three bytes of 
data are used for each Short Audio Descriptor. 

Short Audio Descriptors are defined in Table 60 through Table 64; with Table 60 dealing with L-PCM 
Audio and Compressed Audio formats in the remaining tables. Each Descriptor consists of three data 
bytes. 

In Table 134, as with the Video Data Block, the first byte (0x8C) is used to indicate block type and 
payload length in bytes. Audio Tag Code 1 (0x02) is placed in bits 3 and 7; and bits 0 to 4 contain 0x3 for 
a payload of three bytes. The Short Audio Descriptor begins at address 0x8D and ends with 0x8F. In the 
first byte of the descriptor, bit 7 is reserved and set to ‘zero’. Bits 3 through 6 contain the Audio Format 
code as defined in Table 60; in this example Code 1 for L-PCM is indicated with bit 6. ..3 set to ‘0001’. 

Bits 0 through 2 designate the maximum number of channels as one channel audio (0x1). The second 
descriptor byte uses seven bits to declare frequency characteristics. Frequencies of 32 kHz, 44.1 kHz, 
and 48 kHz are indicated by the 0x07 as defined in Table 60. In address 0x8E; and in the next address 
0x07 is used to declare bit-rates of 16, 20, and 24 bit audio per Table 60. This example does not illustrate 
Short Audio Descriptors for Compressed Audio formats. 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x8C 

0x23 

35 

Audio Data Block 

Start of Audio Block 

0x23 = Audio Block (code = 1) and three 
bytes of data payload. 

0x8 D 

0x09 

9 


Audio Format 

Code 1 = L-PCM (IEC 60985) 

0x8 E 

0x07 

7 


Frequency 

0x07 = 32 kHz, 44.1 kHz, 48 kHz 

0x8 F 

0x07 

7 


Bit Rate 

0x07 = 16 bit, 20 bit, 24 bit 


Table 134 Audio Data Block 


D.6.7 Speaker Allocation Block 

The Speaker Allocation Data Block is used to declare number of speakers and configuration. As with 
preceding blocks a Tag Code and payload length are designated in the first data byte. The data block 
payload begins with the second byte and is used to indicate speaker count and configuration (see Table 
50). The last payload byte is set to zero. 
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In Table 135, address 0x90 contains a value 0x83, which designates the beginning of the Speaker 
Allocation Block and data payload. In this example, the Speaker Allocation Data Block is indicated by 
Code 4 per Table 69. The data payload is set to three bytes. At address 0x91 FL/FR (2 Channel Stereo) 
is chosen by setting the bits to 0x01. The two remaining addresses have the bits set to zero as required 
by Table 54. 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x90 

0x83 

131 

Speaker Allocation Block 

Start of Speaker Allocation 

0x83 =Speaker Allocation 

Data Block (code = 4) and 
three bytes of data payload. 

0x91 

0x01 

1 


Speaker Designation 

0x01 = FL/ FR (2 Channel 
Stereo.) 

0x92 

0x00 

0 


Speaker Designation 

Bits 0 to 2 

0x93 

0x00 

0 


Reserved 

Always zero 


Table 135 Speaker Data Block 


D.6.8 Vendor-Specific Block 

The Vendor-Specific Data Block was originally intended as an option to place data not specified by CTA- 
861; data that a manufacturer may care to use. However, the HDMI specification makes requirements 
that are addressed below. Users are advised to treat this data block with care. 

The first address requires a Tag Code and data payload length in the first byte. The next three addresses 
house a 24-bit IEEE Registration Identifier (three bytes); and a Vendor-Specific Payload in the remaining 
bytes. In the case of HDMI compliant devices the IEEE Registration is used as an ‘HDMI Identifier.’ After 
the HDMI Identifier two bytes are used to identify the port configuration. Users are advised to refer to the 
HDMI specification for details. For the purposes of this example the HDMI Identifier and Physical Source 
Address are presented. 

As shown in Table 136, the first address, 0x94, the Tag Code is listed as ‘3’ and the payload length is set 
to ‘5’ bytes. The second, third and fourth bytes, addresses 0x95, 0x96 and 0x97, contain the HDMI LLC’s 
24-bit IEEE registration Organizationally Unique Identifier (OUI) 0x000C03, which is coded least 
significant byte first. The Physical Source Address is found in address 0x98 and 0x99 and according to 
the HDMI specification, the two bytes are used as Identity Port Configuration with 0x1000 indicating a 
single port Sink. 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x94 

0x65 

101 

Vendor-Specific Data 

Block 

Start of Vendor-Specific 
Block 

0x65 = Vendor-Specific 

Block (code = 3) and five 
bytes of data payload. 

0x95 

0x03 

3 

24-bit IEEE Registration 

HDMI Identifier = 0x000C03 
(The big-endian HDMI-LLC's 
24-bit OUI Registration 
Identifier 0x000C03 is 
placed into the EDID in little- 
endian order.) 

0x96 

OxOC 

12 

0x97 

0x00 

0 

0x98 

0x10 

16 

Components of Source 
Physical Address 

Sink identifies location of 
Source in signal path 
relative to root display as 
ABCD. Example shows input 
T of root display (A=1, B=0, 
C=0, D=0 or 0x1000). 

0x99 

0x00 

0 


Table 136 Vendor-Specific Data Block 
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D.6.9 Complete CTA-861 Example with Block Tag Extension 

Table 137 contains an example implementation of E-EDID utilizing elements of the CTA Block Tag 
Extension that were not addressed in Annex A. These elements are Short Video Descriptors, Audio 
Descriptors, Speaker Allocation Block, and a Vendor-Specific Data Block. This example is applicable to 
HDMI implementations. 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x00 

0x00 

0 

Block Zero Header 


Fixed Value 

0x01 

OxFF 

255 

0x02 

OxFF 

255 

0x03 

OxFF 

255 

0x04 

OxFF 

255 

0x05 

OxFF 

255 

0x06 

OxFF 

255 

0x07 

0x00 

0 

0x08 

OxOC 

12 

Vendor / Product ID 

Manufacturer Name 

CTA 

0x09 

OxAl 

161 

OxOA 

0x00 

0 

Product Code 

Used to differentiate 
between different models 
from the same manufacturer. 

0x0 B 

0x00 

0 

OxOC 

0x00 

0 

Serial Number 

Optional. 

The serial number can also 
be stored in a separate 
descriptor block 

0x0 D 

0x00 

0 

0x0 E 

0x00 

0 

0x0 F 

0x00 

0 

0x10 

0x00 

0 

Week of Manufacture 

Optional. 

If this field is unused, the 
value should be set to 0. 

0x11 

0x0 F 

15 

Year of Manufacture 

Year 2005 

0x12 

0x01 

1 

EDID Structure Version / 
Revision 

Version # 

1 

0x13 

0x03 

3 

Revision # 

3 

0x14 

0x80 

128 

Basic Display Parameters / 
Features 

Video Input Definition 

Digital, VESA DFP1X : not 
compatible 

0x15 

0x50 

80 

Max. Horizontal Image 

Size in cm 

Optional. 

The system should not make 
any assumption regarding 
display size 

0x16 

0x2 D 

45 

Max. Vertical Image Size 
in cm 

Optional. 

See above. 

0x17 

0x78 

120 

Gamma: (gamma x 100)- 
100 = value 

Example is: (gamma = 2.2) 

(2.2 x 100)-100 = 120 

0x18 

OxOA 

10 

Feature Support 

OxOA denotes: 

RGB color Display type, 
preferred timing: first detailed 
timing block. GTF timing: not 
supported. Standby mode: 
not supported, suspend 
mode: not supported, active 
off: not supported 


Table 137 CTA-861 EDID Example with Block Tag Extension 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x19 

0x0 D 

13 

Color Characteristics 

Red/Green Low Bits 


0x1 A 

0xC9 

201 

Blue/White Low Bits 


0x1 B 

OxAO 

160 

Red-x 

0.625 

0x1 C 

0x57 

87 

Red-y 

0.340 

0x1 D 

0x47 

71 

Green-x 

0.280 

0x1 E 

0x98 

152 

Green-y 

0.595 

0x1 F 

0x27 

39 

Blue-x 

0.155 

0x20 

0x12 

18 

Blue-y 

0.070 

0x21 

0x48 

72 

White-x 

0.283 

0x22 

0x4C 

76 

White-y 

0.298 

0x23 

0x20 

32 

Established Timings 

Timing 1 

640x480 @ 60Hz 

0x24 

0x00 

0 

Timing 2 

None 

0x25 

0x00 

0 

Manufacturer's Reserved 
Timing 

None 

0x26 

0x01 

1 

Standard Timing 

ID# 1-8 

Standard Timing ID #1 

PC Application 

0x27 

0x01 

1 

0x28 

0x01 

1 

Standard Timing ID #2 

PC Application 

0x29 

0x01 

1 

0x2A 

0x01 

1 

Standard Timing ID #3 

PC Application 

0x2 B 

0x01 

1 

0x2C 

0x01 

1 

Standard Timing ID #4 

PC Application 

0x2 D 

0x01 

1 

0x2 E 

0x01 

1 

Standard Timing ID #5 

PC Application 

0x2 F 

0x01 

1 

0x30 

0x01 

1 

Standard Timing ID #6 

PC Application 

0x31 

0x01 

1 

0x32 

0x01 

1 

Standard Timing ID #7 

PC Application 

0x33 

0x01 

1 

0x34 

0x01 

1 

Standard Timing ID #8 

PC Application 

0x35 

0x01 

1 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x36 

0x01 

1 

First Detailed Timing 

Descriptor 

(Preferred) 

Pixel Clock 

74.25 MHz 

0x37 

0x1 D 

29 

0x38 

0x80 

128 

H Active 

1920 pixels 

0x39 

0x18 

24 

H Blanking 

280 pixels 

0x3A 

0x71 

113 

H Active: H Blanking 


0x3 B 

0x1 C 

28 

V Active 

540 lines 

0x3C 

0x16 

22 

V Blanking 

22 lines 

0x3 D 

0x20 

32 

V Active: V Blanking 


0x3 E 

0x58 

88 

H Sync Offset 

88 pixels 

0x3 F 

0x2C 

44 

H Sync Pulse Width 

44 pixels 

0x40 

0x25 

37 

VS Offset: VS Pulse 

Width 

2 lines, 5 lines 

0x41 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0x42 

0x20 

32 

H Image Size 

800 mm (lower 8 bits) 

0x43 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0x44 

0x31 

49 

H&V Image Size 

Upper 4 bits of H & V size 

0x45 

0x00 

0 

H Border 

0 pixels 

0x46 

0x00 

0 

V Border 

0 lines 

0x47 

0x9 E 

158 

Flags 

Interlaced, normal display no 
stereo, digital separate, 

Vsync polarity is positive, 
Hsync polarity is positive 

0x48 

0x8C 

140 

Second Detailed Timing 

Descriptor 

(Next Preferred) 

Pixel Clock 

27 MHz 

0x49 

OxOA 

10 

0x4A 

OxDO 

208 

H Active 

720 pixels 

0x4 B 

0x8A 

138 

H Blanking 

138 pixels 

0x4C 

0x20 

32 

H Active: H Blanking 


0x4 D 

OxEO 

224 

V Active 

480 lines 

0x4 E 

0x2 D 

45 

V Blanking 

45 lines 

0x4 F 

0x10 

16 

V Active: V Blanking 


0x50 

0x10 

16 

H Sync Offset 

16 pixels 

0x51 

0x3 E 

62 

H Sync Pulse Width 

62 pixels 

0x52 

0x96 

150 

VS Offset: VS Pulse 

Width 

9 lines, 6 lines 

0x53 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0x54 

0x58 

88 

H Image Size 

600 mm (lower 8 bits) 

0x55 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0x56 

0x21 

33 

H&V Image Size 

Upper 4 bits of H & V size 

0x57 

0x00 

0 

H Border 

0 pixels 

0x58 

0x00 

0 

V Border 

0 lines 

0x59 

0x18 

24 

Flags 

non-interlaced, normal 
display no stereo, digital 
separate, V. and H. sync 
polarity is negative 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x5A 

0x00 

0 

Monitor Descriptor 

Currently Mandatory 
(Monitor Name) 

Flag 


0x5 B 

0x00 

0 

0x5C 

0x00 

0 

Flag (Reserved) 


0x5 D 

OxFC 

252 

Data Type Tag 

Monitor name type 

0x5 E 

0x00 

0 

Flag 


0x5 F 

0x4 D 

77 

M 


0x60 

0x59 

89 

Y 


0x61 

0x20 

32 



0x62 

0x48 

72 

H 


0x63 

0x44 

68 

D 


0x64 

0x54 

84 

T 


0x65 

0x56 

86 

V 


0x66 

OxOA 

10 



0x67 

0x20 

32 



0x68 

0x20 

32 



0x69 

0x20 

32 



0x6A 

0x20 

32 



0x6 B 

0x20 

32 



0x6C 

0x00 

0 

Second Monitor Descriptor 
Currently Mandatory 
(range limits, binary coded) 

Flag 


0x6 D 

0x00 

0 

0x6 E 

0x00 

0 

Flag (Reserved) 


0x6 F 

OxFD 

253 

Data Type Tag 

Monitor Range limits, binary 
coded, mandatory block 

0x70 

0x00 

0 

Flag 


0x71 

0x3 B 

59 

Min Vertical Rate in Hz 

59 Hz 

0x72 

0x3 D 

61 

Max Vertical Rate in Hz 

61 Hz 

0x73 

0x0 F 

15 

Min Horizontal Rate in 
kHz 

15 kHz 

0x74 

0x2 E 

46 

Max Horizontal Rate in 
kHz 

46 kHz 

0x75 

0x08 

8 

Max Supported pixel 
clock rate in MHz/10 

80 MHz 

0x76 

0x00 

0 

Tag for secondary timing 
formula, GTF (0x00=not 
used) 

No secondary timing formula 
supported 

0x77 

OxOA 

10 

Fixed 


0x78 

0x20 

32 

Fixed 


0x79 

0x20 

32 

Fixed 


0x7A 

0x20 

32 

Fixed 


0x7 B 

0x20 

32 

Fixed 


0x7C 

0x20 

32 

Fixed 


0x7 D 

0x20 

32 

Fixed 



Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 


170 




CTA-861-G 


Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x7 E 

0x01 

1 

Extension Flag 

Number of 128 bytes 
blocks to follow 


0x7 F 

OxCO 

192 

Checksum 

Checksum 

Block 0 sum = 

0xFF&(0x100- 

(0x1 B40&0xFF) = OxCO 

0x80 

0x02 

2 

CTA Extension Header 

Tag 

Block One 

0x81 

0x03 

3 


0x03 (see Annex A.2.13) 

Revision Number (Start of 
VESA CTA Block Tag 
Extension) 

0x82 

0x1 A 

26 


0x04, no data in 

Reserved 

Byte Offset 

0x83 

0x71 

113 


Global Declarations 

Content depends on 
implementation DTV, YCbCr 
(4:4:4), YCbCr (4:2:2) 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x84 

0x47 

71 

CTA Data Block Collection 
Video Data Block 

Start of data block 
collection. Includes Tag 
Code and length of 
following data block 
payload 

0x47 = Video Block (code = 

2) and seven bytes of data 
payload 

0x85 

0x85 

133 

1 st Short Video 

Descriptor 

1920x1080i @ 59.94/60 Hz 
16:9 Native Mode 

0x86 

0x02 

4 

2 nd Short Video 

Descriptor 

1280x720p 59.94/60 Hz 16:9 

0x87 

0x03 

3 

3 rd Short Video 

Descriptor 

720x480p 59.94/60 Hz 16:9 

0x88 

0x04 

2 

4 th Short Video 

Descriptor 

720x480p 59.94/60 Hz 4:3 

0x89 

0x06 

6 

5 th Short Video 

Descriptor 

720 (1440)x480i 59.94/60 Hz 
4:3 

0x8A 

0x07 

7 

6 th Short Video 

Descriptor 

720 (1440)x480i 59.94/60 Hz 
16:9 

0x8 B 

0x01 

1 

7 th Short Video 

Descriptor 

640x480p 59.94/60 Hz 4:3 

0x8C 

0x23 

35 

Audio Data Block 

Start of Audio Block 

0x23 = Audio Block (code = 

1) and three bytes of data 
payload. 

0x8 D 

0x09 

9 

Audio Format 

Code 1 = L-PCM (IEC 

60985-3 (121) 

0x8 E 

0x07 

7 

Frequency 

0x07 = 32 kHz, 44.1 kHz, 48 
kHz 

0x8 F 

0x07 

7 

Bit Rate 

0x07 = 16 bit, 20 bit, 24 bit 

0x90 

0x83 

131 

Speaker Allocation Block 

Start of Speaker 

Allocation 

0x83 =Speaker Allocation 

Data Block (code = 4) and 
three bytes of data payload. 

0x91 

0x01 

1 

Speaker Designation 

0x01 = FL/ FR (2 Channel 
Stereo.) 

0x92 

0x00 

0 

Reserved 

Always zero 

0x93 

0x00 

0 

Reserved 

Always zero 

0x94 

0x65 

101 

Vendor-Specific Data 

Block 

Start of Vendor-Specific 
Block 

0x65 = Vendor-Specific 

Block (code = 3) and five 
bytes of data payload. 

0x95 

0x03 

3 

24-bit IEEE Registration 

HDMI Identifier = 0x000C03 
(The big-endian HDMI-LLC's 
24-bit OUI Registration 
Identifier 0x000C03 is placed 
into the EDID in little-endian 
order.) 

0x96 

OxOC 

12 

0x97 

0x00 

0 

0x98 

0x10 

16 

Components of Source 
Physical Address 

Sink identifies location of 
Source in signal path relative 
to root display as ABCD. 
Example shows input T of 
root display (A=1, B=0, C=0, 
D=0 or 0x1000). 

0x99 

0x00 

0 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0x9A 

0x01 

1 

Third Detailed Timing 
Descriptor 

Pixel Clock 

74.25 MHz 

0x9 B 

0x1 D 

29 



0x9C 

0x00 

0 

H Active 

1280 pixels 

0x9 D 

0x72 

114 

H Blanking 

370 pixels 

0x9 E 

0x51 

81 

H Active: H Blanking 


0x9 F 

OxDO 

208 

V Active 

720 lines 

OxAO 

0x1 E 

30 

V Blanking 

30 lines 

OxAl 

0x20 

32 

V Active: V Blanking 


0xA2 

0x6 E 

110 

H Sync Offset 

110 pixels 

0xA3 

0x28 

40 

H Sync Pulse Width 

40 pixels 

0xA4 

0x55 

85 

VS Offset: VS Pulse 

Width 

Sync Offset = 5 lines, Sync 
width = 5 lines 

0xA5 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0xA6 

0x20 

32 

H Image Size 

800 mm (lower 8 bits) 

0xA7 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

0xA8 

0x31 

49 

H&V Image Size 

Upper 4 bits of H & V size 

0xA9 

0x00 

0 

H Border 

0 pixels 

OxAA 

0x00 

0 

V Border 

0 lines 

OxAB 

0x1 E 

30 

Flags 

Non-interlaced, normal 
display no stereo, digital 
separate, H and V sync 
polarity is positive 

OxAC 

0x8C 

140 

Fourth Detailed Timing 
Descriptor 

Pixel Clock 

27 MHz 

OxAD 

OxOA 

10 



OxAE 

OxAO 

160 

H Active 

1440 pixels 

OxAF 

0x14 

20 

H Blanking 

276 pixels 

OxBO 

0x51 

81 

H Active: H Blanking 


OxBI 

OxFO 

240 

V Active 

240 lines 

0xB2 

0x16 

22 

V Blanking 

22 lines 

0xB3 

0x00 

0 

V Active: V Blanking 


0xB4 

0x26 

38 

H Sync Offset 

38 pixels 

0xB5 

0x7 C 

124 

H Sync Pulse Width 

124 pixels 

0xB6 

0x43 

67 

VS Offset: VS Pulse 

Width 

Sync Offset = 4 lines, Sync 
width = 3 lines 

0xB7 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


0xB8 

0x58 

88 

H Image Size 

600 mm (lower 8 bits) 

0xB9 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

OxBA 

0x21 

33 

H&V Image Size 

Upper 4 bits of H & V size 

OxBB 

0x00 

0 

H Border 

0 pixels 

OxBC 

0x00 

0 

V Border 

0 lines 

OxBD 

0x98 

152 

Flags 

interlaced, normal display no 
stereo, digital separate, V. 
and H. sync polarity is 
negative, 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

OxBE 

0x8C 

140 

Fifth Detailed Timing 
Descriptor 

Pixel Clock 

27 MHz 

OxBF 

OxOA 

10 



OxCO 

OxDO 

208 

H Active 

720 pixels 

OxCI 

0x8A 

138 

H Blanking 

138 pixels 

0xC2 

0x20 

32 

H Active: H Blanking 


0xC3 

OxEO 

224 

V Active 

480 lines 

0xC4 

0x2 D 

45 

V Blanking 

45 lines 

0xC5 

0x10 

16 

V Active: V Blanking 


0xC6 

0x10 

16 

H Sync Offset 

16 pixels 

0xC7 

0x3 E 

62 

H Sync Pulse Width 

64 pixels 

0xC8 

0x96 

150 

VS Offset: VS Pulse 

Width 

Sync Offset= 9 lines, Sync 
width = 6 

0xC9 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


OxCA 

0x20 

32 

H Image Size 

800 mm (lower 8 bits) 

OxCB 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

OxCC 

0x31 

49 

H&V Image Size 

Upper 4 bits of H&V size 

OxCD 

0x00 

0 

H Border 

0 pixels 

OxCE 

0x00 

0 

V Border 

0 lines 

OxCF 

0x18 

24 

Flags 

Non-interlaced, normal 
display no stereo, digital 
separate, V. and H. sync 
polarity is negative, 

OxDO 

0x8C 

140 

Sixth Detailed Timing 
Descriptor 

Pixel Clock 

27 MHz 

OxDI 

OxOA 

10 



0xD2 

OxAO 

160 

H Active 

1440 pixels 

0xD3 

0x14 

20 

H Blanking 

276 pixels 

0xD4 

0x51 

81 

H Active: H Blanking 


0xD5 

OxFO 

240 

V Active 

240 lines 

0xD6 

0x16 

22 

V Blanking 

22 lines 

0xD7 

0x00 

0 

V Active: V Blanking 


0xD8 

0x26 

38 

H Sync Offset 

38 pixels 

0xD9 

0x7 C 

124 

H Sync Pulse Width 

124 pixels 

OxDA 

0x43 

67 

VS Offset: VS Pulse 

Width 

Sync Offset = 4 lines, Sync 
Width = 3 lines 

OxDB 

0x00 

0 

HS Offset: HS Pulse 

Width: VS Offset: VS 

Pulse Width 


OxDC 

0x20 

32 

H Image Size 

800 mm (lower 8 bits) 

OxDD 

0xC2 

194 

V Image Size 

450 mm (lower 8 bits) 

OxDE 

0x31 

49 

H&V Image Size 

Upper 4 bits of H & V size 

OxDF 

0x00 

0 

H Border 

0 pixels 

OxEO 

0x00 

0 

V Border 

0 lines 

OxEI 

0x98 

152 

Flags 

interlaced, normal display no 
stereo, digital separate, V. 
and H. sync polarity is 
negative 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Address 

Hex 

Example Data 
Hex Dec 

Name of Block 

Description 

Remarks 

0xE2 

0x00 

0 

Padding Bytes 



0xE3 

0x00 

0 



0xE4 

0x00 

0 



0xE5 

0x00 

0 



0xE6 

0x00 

0 



0xE7 

0x00 

0 



0xE8 

0x00 

0 



0xE9 

0x00 

0 



OxEA 

0x00 

0 



OxEB 

0x00 

0 



OxEC 

0x00 

0 



OxED 

0x00 

0 



OxEE 

0x00 

0 



OxEF 

0x00 

0 



OxFO 

0x00 

0 



OxFI 

0x00 

0 



0xF2 

0x00 

0 



0xF3 

0x00 

0 



0xF4 

0x00 

0 



0xF5 

0x00 

0 



0xF6 

0x00 

0 



0xF7 

0x00 

0 



0xF8 

0x00 

0 



0xF9 

0x00 

0 



OxFA 

0x00 

0 



OxFB 

0x00 

0 



OxFC 

0x00 

0 



OxFD 

0x00 

0 



OxFE 

0x00 

0 



OxFF 

0x7A 

122 

Checksum 


Block 1 sum = 

0xFF&(0x100- 
(0x1686&0xFF) = 0x7A 


Table 137 CTA-861 EDID Example with Block Tag Extension (continued) 
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Annex E [Reserved for Future Use] 
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Annex F Guidance for Source & Sinks (Informative) 

F.1 Overview 

This Annex is intended to augment Section 7.2.3 “Source Guidance” and provide background and more 
detail to the recommendations therein. 

The essence of that guidance is thus: video Sources should provide a Source Pass-through mode for 
content in its Native Video Format (avoiding scaling, frame rate converting interlacing, and deinterlacing). 
By using Source Pass-through Mode, it is more likely that only one (if any) format conversion occurs. 
When more than one format conversion occurs, generally more artifacts become evident in the content 
being presented. However, applying Source Pass-through Mode is dependent on the use case in which 
content is being viewed. 

Consistent application of the recommendations herein will help create to an ecosystem of CTA-861 
conformant devices with the best possible out of box experience for consumers, regardless of brand 
name purchased. 

F.2 Background 

The video processing chain from content production to presentation is envisioned as a set of black boxes 
that are integral to video distribution as shown in Figure 9. It does not show the audio processing chain. 



Physical Media Distribution meta-data 


Figure 9 Video Processing Chain 

Examples of Sources include CE devices (e.g., STBs, DVD players), IT devices (e.g., PCs), and 
convergent devices (e.g., PC/STB). Examples of Sinks are DTVs, PC Monitors and possible convergent 
display devices (repeaters and splitters are not dealt with in this Annex). 

The main interface of concern treated here is, the “Uncompressed data/Limited meta-data” link between 
the Source and the Sink. 

Because the Sink (in this case assumed to be a rendering device) is the last component in the device 
chain, it is incapable of enforcing any control over preceding devices with respect to video processing. 
Furthermore as there is no closed loop communication between Sinks and Sources, these devices cannot 
negotiate as to where a certain function should or will be carried out (i.e., - scaling). To assure best 
performance of a complete system, a set of guidelines for default behavior, especially for Sources, is 
needed. Two common usage scenarios exist that dictate different default behaviors. 

1. Use cases where the source material’s Video Format is stable and unchanging for an extended 
period of time, (i.e., - playback of a movie). 

2. Use cases where the source material’s Video Format is often changing (i.e., - channel surfing). 

F.3 Guidance for Sources 
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F.3.1 Stable Video Format 

Recommended default setting for use cases where a Video Format is expected to be stable: The Source 
should transmit video in its Native Video Format directly to the Sink without interlacing, deinterlacing, 
frame rate converting or scaling (see Source Pass-through Mode), provided that support for that format is 
indicated in the Sink’s EDID. Examples of this are illustrated in Figure 10 (b) and Figure 11 (d) & (f). 
Figure 10 (b) and Figure 11 (c) & (e) are examples of not passing through the Native Video Format, 
resulting in multiple conversions. 

a. Use cases that are covered by this recommendation include: 

i. Playback from an optical disc player. 22 

ii. Playback from a Digital Video Camera (usually recorded at a single resolution). 

iii. Presentation of an IT device. 

iv. Playback of premium content from a STB. 

b. The reason this setting is recommended as default is that: 

i. Sink (display) devices are often built with high quality signal processing (scaling, etc.) 
capabilities as a key differentiating feature. Although there are Sources that deliver excellent 
scaling ability, most Sources are optimized to deliver their key function (i.e., optical playback, 
interface to the managed network). 

ii. Display devices are optimized to process signaling based on their own characteristics and 
properties. These properties may shift over the life of a display, temperature, and on-time, 
among other possibilities. Only the display itself is capable of monitoring and compensating 
for these shifts in parameters, nor is there a way for a Sink to completely communicate such 
parameters to a Source. 

c. The Source Pass-through Mode does not exclude the possibility of graphics overlay onto the original 
content (e.g., User Interface, Closed Captions, etc.). 

d. For IT Sources that place the video content inside a fixed or resizable window, these rules do not 
necessarily apply. 


F.3.2 Changing Video Format 

Recommended default setting for use cases where a Video Format is expected to change often. The 
Source should, by default, generate video in the Preferred Timing Format of the Sink. Examples of this 
are shown in Figure 10 (a) and Figure 11 (c) & (e). 

a. Use cases that are covered by this recommendation include: 

i. Playback from a STB where the user is channel surfing. 

ii. Playback of broadcasts where the native resolution of the transmission stream is changing 
often (e.g., - program splicing, dynamic ad insertion). 


22 In spite of the fact that previews, or other features may be in different formats than the full length 
feature, users will tolerate video muting when switching modes (i.e., - switching from menu to main 
feature). Viewing of full length features will be optimized. 
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MPEG source 
format (as decoded) 


Interface 


Sink 



16:9 Display 


Figure 10 Example of Options for Format Conversion 

In the example shown in Figure 10, the Sink indicates by its EDID data that it has a preferred format of 
1080i, and that it can accept 1080i, 720p, 480i, or 480p. In the cases labeled (a), the conversion from the 
source material (which may be received and decoded as 1080i, 720p, 480i or480p) to 1080i is happening 
in the Source. In the other case, labeled (b), the Source does no format conversion and delivers the as- 
decoded format across the interface. Conversion to 1080i is happening in the Sink. If the Sink is a multi¬ 
scan capable display and indicates the other formats are supported natively also, the best image 
presentation probably results if the conversion takes place in the Sink. 
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MPEG source 
format (as decoded) 


Interface 



1080i 


720p 


480i 


480p 


Sink 


(pref.) 


(d) 


a 


16:9 1024x576 
LCD Display 




(f) 


Figure 11 Multiple Conversions Example 

In the example in Figure 11 the Sink can once again support 1080i, 720p, 480i, or480p. In this case, the 
display is a 1024 by 576 LCD panel so none of these formats is native, and 720p is indicated as being 
“preferred.” The illustration shows conversions either taking place in the Source, in the Display, or in both. 
Any conversion performed in the Source is to 720p because 720p is indicated as the preferred format. 
This is a situation where at least one conversion takes place. In general, format conversions introduce 
errors and display artifacts. In the optimum system, at most one format conversion should be done 
between the MPEG-2 decoder and visual presentation. In Figure 11, MPEG-2 video in 1080i format is 
decoded, and can be converted (c) into the Sink’s preferred 720p format. In this case, the Display re¬ 
converts 720p into its native 1024x576 LCD format. Alternatively, the 1080i video can be delivered un¬ 
converted across the interface (d) where the Display performs one conversion to its Native Video Format. 
The cases marked (e) are similar, in that two conversions result if the Source re-formats into 720p before 
delivering the data across the interface. In the remaining cases the video is delivered in the same format 
as it was decoded, resulting in only one conversion. These cases illustrate that the best visual 
presentation may result when the Source transports (passes through) the video to the Sink in the same 
basic format as the decoded MPEG2 stream (assuming the ultimate source is MPEG2). 


F.3.3 Optional User Controlled Setting 

Naturally, user accessible features to override default settings in Sources are allowed. These types of 
user controls enable flexibility beyond the recommendations above. Such controls could enable better 
picture quality in the case of, for instance, use of an A/V receiver containing a high quality image 
processor. In such a case, it might be better to utilize the image processor of the A/V receiver, rather than 
allowing the display device to handle the video processing (the default recommendation). 


F.3.4 Non-Default Scenarios 

When a Source is incapable of supporting the recommendations in Sections F.3.1 & F.3.2 above, then it 
should still follow the general recommendations for the appropriate use case, (i.e., following or not 
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following the source material Video Format at its output). In such circumstances (i.e., Native Video Format 
of video source, or preferred timing mode not supported) the Source should generate an appropriate 
Video Format at its output, following the rules of precedence described in CTA-861 (based on the 
ordering of Video Formats in EDID). 

a. The Source should first attempt to convert the content to the Video Format described at the lowest 
address in the EDID. 

b. If the Source cannot convert to the first format listed in the EDID, then it should transform the content 
to the Video Format described at the next lowest address. If the second format is not supported by the 
Source, then the Source should continue looking until it finds a supported format, with earlier formats 
being preferred over later ones. The Source may also use other criteria to decide between formats 
listed in the EDID, such as the criteria listed in item c. 

c. If the Source needs to transform the Video Format, it is recommended that transformations be made in 
the following order of precedence, in order to minimize video artifacts. 

i. Image cropping where applicable. (Note: Content that requires a small fractional vertical 
“downscale”, like 1920x1088 @ 60Hz to 1920x1080 @ 60Hz, should simply be cropped. 

Cropping is commonly required when content originates from a video codec format (e.g., ISO/IEC 
13818-2 [73]) encoded with a vertical size of 1088 lines. In this case, the Source generally crops 
the bottom 8 lines of the originally coded content prior to outputting it in a 1080i/1080p format.) 

ii. Horizontal upscale but no frame rate conversion (e.g., 1440x1080 @ 60Hz to 1920x1080 @ 

60Hz or 704x480 @ 59.94Hz to 720x480 @ 59.94Hz) 

iii. Vertical & horizontal upscale but no frame rate conversion (e.g., 720x576 @ 50Hz to 1280x720 
@ 50Hz) 

iv. Vertical & horizontal downscale but no frame rate conversion (e.g., 1280x720 @ 50Hz to 720x480 
@ 50Hz) 

v. Any frame rate conversion (e.g., 720x576 @ 50Hz to 720x480 @ 59.94Hz) 

d. The Source should maintain video content in its original color space if the Sink accepts that color 
space 

i. If the Sink accepts video content in YCbCr color space and the Source receives or generates video 
content in the same YCbCr color space, the Source should simply pass-through the video content 
in that color space (see Source Pass-Through Mode). If the Source is additionally required to blend 
RGB encoded graphics planes (e.g., Closed Captions and Electronic Program Guide data) with the 
video content, it is preferable for the Source to convert the graphics planes to the YCbCr color 
space of the video content prior to blending. 

ii. If the Sink only accepts video content in RGB color space the Source should perform a YCbCr to 
RGB color space conversion after all image enhancement processes (e.g., scaling, interlacing, 
deinterlacing, noise reduction, frame rate conversion, etc.) have been applied. 

e. Sources capable of sending InfoFrames are required (per Section 6.4) to send accurate information 
regarding any video transformation done in the Source, via an Auxiliary InfoFrame (AVI), provided the 
Sink accepts InfoFrames. 


F.3.5 Errors Reading the EDID 

a. If an EDID read fails (i.e., incorrect checksum), the Source should attempt to re-read the EDID. 

b. If after numerous attempts, the EDID read still fails, the Source may utilize portions of the data that 
seem valid. 

c. If the EDID is not at all decipherable, the Source should generate one of the default Sink Video 
Formats defined in Section 3.1 and shown in Table 1. The Source should avoid transmitting audio 
across the interface. If the Source can determine that the Sink is CTA-861-compliant, then it may 
supply 720X480p or 720x576p since support for this format timing is required in all CTA-861 
conformant Sinks. If the Source can determine the Preferred Picture Aspect Ratio for that format, then it 
should use that Picture Aspect Ratio. If the Source cannot determine that the Sink is CTA-861 
conformant, then it should output 640x480p if it is capable of that format. If it cannot output 640x480p, 
then it should output 720X480p or 720x576p. 
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F.3.6 Video Timing Transition (AVMUTE Recommendation) 

The Source should wait a minimum of three Video Fields following the assertion of AVMUTE before 
stopping or changing video timing. The Source should also allow sufficient time (e.g., typically a minimum 
of five Video Fields) for the Sink to synchronize to the incoming signal before clearing AVMUTE. 

Following this recommendation helps assure that audio and video noise are neither seen nor heard 
during timing changes and that encryption systems recover reliably afterwards. 

F.4 Guidance for Sinks 
F.4.1 Valid Read-Only EDID 

a. As required in Section 7 a Sink indicates support for 640x480p Video Format in the EDID Detailed 
Timing Descriptors and/or the Short Video Descriptors. 

b. If during the course of operation a Sink modifies the contents of its EDID such that the Video Formats 
previously defined and read by Source have changed, then the Sink should indicate the change via a Hot 
Plug Event, (see Annex A.2.19) 


F.4.2 Ordering of the Video Formats in the EDID 

Ordering of the Video Formats in EDID is critical to assure optimal performance of the complete system 
(assuming that Sources follow the rules described in “Guidance for Sources”). 

a. The first Video Format listed (in the first DTD of the base block) should be the manufacturer’s most 
preferred timing, which might provide optimal video quality. The second best format in terms of preference 
should be listed as the second Video Format (either in the second DTD or in the first or second SVD). 

The third best format should be listed in the third position. Subsequent formats, each having lower 
preference than the preceding one, should be listed in subsequent positions. 

b. Designers should think carefully about the use cases described in the Source guidance section of this 
annex, and order EDID so as to minimize the instances in which scaling might occur more than once. 

The sequential order of Video Formats in EDID should be created according to the Sink's capabilities. 

The most preferred Video Format should be listed first and the next preferred format should be listed 
second, etc. Video formats not supported by the Sink should not be listed in EDID. Consideration of 
methods Sources might employ to determine an appropriate Video Format is advised. 


F.4.3 Video Information Code (VIC) Transition 

After receiving an AVI InfoFrame carrying a Video Identification Code (VIC) that is different than the 
preceding VIC, the Sink should execute a mode switch as rapidly as possible, not checking the format of 
video itself, but assuming that the transmitted VIC is correct. This is recommended in order to minimize 
video muting between mode switches. 

a. Just prior to executing a mode switch, the Sink should mute video such that any video artifacts that 
could potentially be displayed during the switch are masked from the user. The Sink should un-mute 
video after the mode switch. 

b. In addition, the Sink should also support AVMUTE functionality - so that muting may be directly 
controlled by Source commands. 
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Annex G InfoPacket Framework (Informative) 

Previous versions of CTA-861 defined an InfoPacket data structure that could be used to bundle one or 
more InfoFrames together for transmission across an existing digital interface. The InfoPacket 
mechanism is not used in any current interface and is not expected to be used in any future interface and 
so has been deprecated. 
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Annex H Active Format Description (Informative) 

This Annex describes the application of Active Format Description for video coded as constrained by the 
Advanced Television Systems Committee system (ATSC) and by the Digital Video Broadcast system 
(DVB). 


H.1 ATSC Active Format Description 

This section is extracted from CTA-CEB16-A Active Format Description (AFD) & Bar Data Recommended 
Practice [67]. 

Figure 12 illustrates the meanings of the bounding rectangles, gray areas, and white circles as used in 
Table 138. Table 138 illustrates the AFD codes expected to be used in North America (ATSC System). 
The meaning of each AFD value is Coded Frame context sensitive and each is defined in Table 138. The 
names used for ATSC systems are intentionally different from those used in Europe as the default actions 
are more specific based on the particular configuration of receiving and display equipment. CTA-CEB16- 
A [67] contains more detailed characterizations of the frame contents as it adds Bars that indicate black 
or gray generated by the receiver (either in the decoder or display). CTA-CEB16-A recommends receiver 
actions upon receipt of each code depending on video content which is transmitted to the CTA-861 
interface and depending on characteristics of the display. 


Bounding box represents 
the coded frame 


Shaded regions lie outside the smallest rectangle 
enclosing the circular regions and indicate active video 
areas that may be cropped by the receiver without 
significant loss to the viewer 


Black regions indicate areas of 
the picture that do not contain 
useful information and should 
be cropped by the receiver 
where appropriate 



White regions lie inside the smallest rectangle 
enclosing the circular regions and indicate the 
area of essential picture information which 
should always be displayed by all receivers 


Figure 12 Active Format Illustration (ATSC) 


Definitions: 


Coded Frame A Picture within a compressed video stream such as MPEG2 that is coded as a single 

frame or as two fields. 

Coded Frame Aspect The Picture Aspect Ratio associated with the Coded Frame of a compressed video stream 
Ratio such as MPEG2. It is either 4:3 or 16:9. 


Indicates the portion of the Active Image which may be cropped for optimum display as 
appropriate to the aspect ratio of the display screen 



Indicates a matte, often black, which is transmitted as part of the video Coded Frame to fill 
the area outside the Active Image 
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active_format 

‘ 0000 ’ 

‘ 0001 ’ 


4:3 Coded Frames 
No AFD Specified 
Reserved 


Description 

16:9 Coded Frames 
No AFD Specified 
Reserved 


‘0010’-‘001 r 

‘ 0100 ’ 

‘ 0101 ’ — ‘ 0111 ’ 

‘ 1000 ’ 

‘ 1001 ’ 

‘ 1010 ’ 

‘ 1011 ’ 

‘ 1100 ’ 

‘ 1101 ’ 

‘ 1110 ’ 

‘ 1111 ’ 


Not documented 

Greater than 
16:9 

letterbox 

image 

Reserved 


4:3 full frame 
image 


4:3 full frame 
image 


16:9 

letterbox 

image 


14:9 

letterbox 

image 

Reserved 
4:3 full 

frame image, 
alternative 
14:9 center 

16:9 

letterbox 
image, 
alternative 
14:9 center 
16:9 

letterbox 
image, 
alternative 
4:3 center 


use in US 



Not documented for use in US 


Greater than 
16:9 

letterbox 

image 

Reserved 


16:9 full 
frame image 


4:3 pillarbox 
image 


16:9 full 
frame image 


14:9 pillarbox 
image 


Reserved 


4:3 pillarbox 
image, 
alternative 
14:9 center 


16:9 full 
frame image, 
alternative 
14:9 center 


16:9 full 
frame image, 
alternative 
4:3 center 



Table 138 Illustrated ATSC AFD Coding 
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H.2 DVB Active Format Description 

See Annex B of ETSI TS 101 154 [68] for implementation guidance in DVB systems, portions of which 
are replicated below for the convenience of the reader. 

Figure 13 illustrates the meanings of the bounding rectangles, gray areas, and white circles as used in 
Table 139. Table 139 illustrates the AFD codes expected to be used in Europe (DVB System) 


Bounding box represents 
the coded frame \ 



Black regions indicate areas of 
the picture that do not contain 
useful information and should 
be cropped by the receiver 
where appropriate 



Gray regions that lie outside the smallest rectangle 
enclosing the white regions indicate areas of the picture 
that may be cropped by the receiver without significant 
loss to the viewer 


The smallest rectangle enclosing the white 
regions indicates the area of essential picture 
information which should always be 
displayed by all receivers 


Figure 13 Active Format lliustration (DVB) 


Definitions: 


Coded Frame 


Coded Frame 
Aspect Ratio 


A Picture within a compressed video stream such as MPEG2 that is coded as a 
single frame or as two fields. 

The Picture Aspect Ratio associated with the Coded Frame of a compressed 
video stream such as MPEG2. It is either 4:3 or 16:9. 
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Table 139 Illustrated DVB AFD Coding 
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Annex I [ Intentionally Omitted ] 
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Annex J [ Intentionally Omitted ] 


189 



CTA-861-G 


Annex K Audio Speaker Placement & Channel Allocation Compatibility (Informative) 

CTA-861 does not exactly follow professional broadcast/production industry (i.e., MPGA, ITU, or SMPTE) 
speaker placement and audio channel allocation standards. 

Table 140 compares the speaker placements between the SMPTE 2035 [63] and CTA-861 standards. 
There is general agreement between 5.1 channels - although the exact audio channel descriptions and 
abbreviations are slightly different. All other channels have no direct equivalents. 


( SMPTE 2035 [63] 

CTA-861 | 

Audio channel 

Abbreviation 

Abbreviation 

Audio Channel 

Left 

L 

FL 

Front Left 

Center 

C 

FC 

Front Center 

Right 

R 

FR 

Front Right 

Left surround 

LS 

LS 

Left Surround 

Right surround 

RS 

RS 

Right Surround 

Low-frequency effects 

LFE 

LFE1 

Low Frequency Effect 

Mono surround 

MS 

BC 

Back Center 

Mono surround at a —3 dB level 

iimsiiiEsims! 



Left total 

Lt 



Right total 

Rt 



Stereo left 

Lo 



Stereo right 

Ro 



Monophonic 

M 



Freely usable 




Unassigned / unused 

U 





FLC 

Front Left Center 



FLW 

Front Left Wide 



TpFL 

Front Left High 



FRC 

Front Right Center 



FRW 

Front Right Wide 



TpFR 

Front Right High 



TpFC 

Front Center High 



RC 

Rear Center 



RLC 

Rear Left Center 



RRC 

Rear Right Center 



TpC 

Top Center 


Table 140 SMPTE/CTA Audio Channel Description & Abbreviation Comparison 


Table 141 compares the channel assignments between SMPTE 2035 [63] and CTA-861 standards. Here 
again, there is general agreement between the 5.1 channels except for the FC and LFE channels, which 
are swapped. 


Channel 

SMPTE 2035 

CTA-861 

1 

L 

FL 

2 

R 

FR 

3 

C 

LFE1 

4 

LFE 

FC 

5 

LS 

SL or RC 

6 

RS 

SR 

7 

Lt or Lo 

BC, RLC, FLC, TpFC, FLH, or FLW 

8 

Rt or Ro 

RRC, FRC, TC, FRH, FRW, or TpFC 


Table 141 SMPTE/CTA Audio Channel Assignment Comparison 
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Annex L Video Timing Examples (Informative) 

This section gives three examples showing how tabular data from Table 1 and Table 2 is applied to the 
generalized waveforms of Figure 1, Figure 2, and Figure 5 for selected Video Timings. In these examples, 
all variables are replaced by specific values either taken directly from the tables or calculated using table 
values. Values for all of the line numbering variables are given in the table attached to the lower-left of 
each figure. These values also replace the respective variables in the figure. 



Figure 14 General Progressive Example for Video ID Codes 2 & 3 (720x480p @ 60 Hz) 
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2200 


Data 

Enable 


' 280 





HSYNC 


148 


1920 



Field 1: 22 (lines) 


- 1 *- 

Top Line 


Data 

Enable 


HSYNC 


VSYNC 


88 H 


2 (lines) 5 (lines) 


N-H 2200 




/ / J 


h 

(1124) 


( 1 ) 


15 (lines) 


540 (lines) 

7 / 


b I 
( 6 ) 


/ / 


/ /- 


( 21 ) 


d I 

(561) 


Field 2: 23 (lines) 


Data 

Enable 


HSYNC 


VSYNC 


88 H 


2.5 (lines) 


1100 


/ / 


d 

(561) 


5 (lines) 


// J 

(5$3) (568) 


15.5 (lines) 


540 (lines) 

/ / 


/ / 


/ 


g 

(584) 


I h | 

(1124) 


a 

i 

Dimensional values in pixel clocks, except where (lines) noted 

b 

6 

Letters a, b, c, ... represent line numbers 

c 

21 


d 

561 


e 

563 


f 

568 


g 

584 


h 

1124 



Figure 15 General Interlace Example for Video ID Code 5 (1920x1080i @ 60 Hz) 
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Data 

Enable 



168 

32 ^ 


HSYNC 


Data 

Enable 


Field 1: 85 (lines) 


VSYNC 


Top Line , 


540 (lines) 




Field 2: 85 (lines) 


540 (lines) 


Data 

Enable 



| d | e 

(603) (625) 



VSYNC 


Dimensional values in pixel clocks, except where (lines) noted 
Letters a, b, c, ... represent line numbers 


Figure 16 Special Interlace Example for Video ID Code 39 (1920x1080i-1250 Vtotal @ 50 Hz) 
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Annex M AFD Bar Data Conversion Examples (Informative) 

This section provides AFD Bar Data conversion examples. The input Bar Data is taken from two 
examples given in Annex B of SMPTE 2016-1. Each example is worked below to demonstrate the proper 
calculation of equivalent CTA-861 Bar Data. 


M.1 Converting 720p 2.4:1 Letterbox Bar Data 

The first example (B.1) is a progressive scan 720p Video Format with 2.4:1 centered letterbox (93-line 
horizontal Bar at top, 533-line Active Image, and 94-line horizontal Bar at bottom) with Bar Data 
top_bar_flag=1, bottom_bar_flag=1, left_bar_flag=0 and right_bar_flag=0, 
line_number_end_of_top_bar=118, and line_number_start_of_bottom_bar=652. 

SMPTE 2016-1 Bar flags top_bar_flag=1 and bottom_bar_flag=1 indicate that horizontal Bar Data is 
present and that Bar Data values line_number_end_of_top_bar and line_number_start_of_bottom_bar 
need to be converted to equivalent CTA-861 InfoFrame Bar Data values ETB and SBB using the equation 
from Table 24 as follows: 

ETB = line_number_end_of_top_bar - Ln - Vsync-Vback + 1 = 118-1-5-20+1 = 93 
SBB = line_number_start_of_bottom_bar - Ln - Vsync - Vback + 1 = 652-1-5-20+1 = 627 
Since horizontal Bars are present (top_bar_flag=1 or bottom_bar_flag=1), B1=1. 

Since SMPTE 2016-1 left Bar flag indicates that no left vertical Bar is present (left_bar_flag=0), CTA-861 
InfoFrame left Bar Data ELB is set to a special value as follows: 

ELB = 0 

Since SMPTE 2016-1 right Bar flag indicates that no right vertical Bar is present (right_bar_flag=0), CTA- 
861 InfoFrame right Bar Data SRB is set to a special value as follows: 

SRB = Hactive+1 = 1280+1 = 1281. 

Since neither vertical Bars are present (Ieft bar_flag=0 and right_bar_flag=0), B0=0. 


M.2 Converting 1080i 2.4:1 Letterbox Bar Data 

The second example (B.2) is an interlaced scan 1080i Video Format with 2.4:1 centered letterbox (140- 
line horizontal Bar at top, 800-line Active Image, and 140-line horizontal Bar at bottom) with Bar Data 

top_bar_flag=1, bottom_bar_flag=1, left_bar_flag=0, right_bar_flag=0, line_number_end_of_top_bar=653, 

and line_number_start_of_bottom_bar=491. 

SMPTE 2016-1 Bar flags top_bar_flag=1 and bottom_bar_flag=1 indicate that horizontal Bar Data is 
present and that Bar Data values line_number_end_of_top_bar and line_number_start_of_bottom_bar 
need to be converted to equivalent CTA-861 InfoFrame Bar Data values ETB and SBB using equations 
from Table 23 as follows: 

Since 653 > [1 + (1080/2)] and 1080i is not “480 Interlaced”, use Field 2 “Other Interlaced” equation for 
ETB calculation. 

ETB = 2*[line_number_end_of_top_bar - Ln - Vfront - 2*(Vsync + Vback) - (Vactive/2)] 

= 2*[653-1-2-2*(5+15)-(1080/2)] = 140 

Since 491 <= [1 + (1080/2)] and 1080i is not “480 Interlaced”, use Field 1 “Other Interlaced” equation for 
SBB calculation. 
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SBB = 2*[line_number_start_of_bottom_bar - Ln - Vsync - Vback + 1] -1 
= 2*[491-1-5-15+1]-1 = 941 

Since horizontal Bars are present (top_bar_flag=1 or bottom_bar_flag=1), B1 =1. 

Since SMPTE 2016-1 left Bar flag indicates that no left vertical Bar is present (left_bar_fiag=0), CTA-861 
InfoFrame left Bar Data ELB is set to a special value as follows: 

ELB = 0 

Since SMPTE 2016-1 right Bar flag indicates that no right vertical Bar is present (right bar_flag=0), CTA- 
861 InfoFrame right Bar Data SRB is set to a special value as follows: 

SRB = Hactive+1 = 1920+1 = 1921. 

Since neither vertical Bars are present (I eftb a r_f I a g=0 and right_bar_fiag=0), B0=0. 


195 



CTA-861-G 


Annex N Video Format Structure (Informative) 

This section provides a graphical representation of a Video Format. 


Width Dimension 

,, . . . - = Picture Aspect Ratio 

Height Dimension 

Picture (Total Image) 



Figure 17 Video Format Structure 
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Annex O Sync, Pixel, and Interface-specific Data Clock Relationships (Informative) 

This section provides a graphical representation of the relationships between CTA-861’s Pixel Clock, 
Sync, Active Pixels, Unique Active Pixels, and a hypothetical interface-specific data clock for various 
combinations of chroma sampling (4:4:4, 4:2:2, 4:2:0), Component Depth (8-bit, 10-bit, 12-bit, 16-bit per 
component), and pixel repetition (PR). 






Data Clock 4:4:4 or 4:2:0 16-bit Deep Color 


Data Clock 4:4:4 or 4:2:0 12-bit Deep Color 


Data Clock 4:4:4 or 4:2:0 10-bit Deep Color 


Data Clock 4:4:4 or 4:2:0 8-bit, 4:2:2 10-bit or 12-bit 


Pixel Clock 


Sync (aligned with Pixel Clock) 



Active Pixels (aligned with Pixel Clock) 


Unique Active Pixels 4:2:0 PR=0 


Unique Active Pixels 4:4:4 or 4:2:2 PR=0 


Unique Active Pixels 4:4:4 or 4:2:2 PR=1 


Unique Active Pixels 4:4:4 or 4:2:2 PR=2 


Unique Active Pixels 4:4:4 or 4:2:2 PR=3 


Unique Active Pixels 4:4:4 or 4:2:2 PR=4 


Figure 18 Active Pixels, Unique Active Pixels, Pixel Clock, Data Clock, and Sync Relationships 


Mode 

Actual Pixel Clock Frequency 

2D 4:4:4 

Table 1 Listed Pixel Clock Frequency(VIC) 

2D 4:2:2 

Table 1 Listed Pixel Clock Frequency(VIC) 

2D 4:2:0 

Table 1 Listed Pixel Clock Frequency(VIC)/2 

3D 4:4:4 or 4:2:2 

Table 1 Listed Pixel Clock Frequency(VIC)*2 

3D 4:2:0 

Table 1 Listed Pixel Clock Frequency(VIC) 


Table 142 Pixel Clock Frequency Modification 


197 









CTA-861-G 


Annex P Calculation of MaxCLL and MaxFALL (Normative) 

The values of MaxCLL and MaxFALL shall be calculated as follows: 

P.1 MaxCLL 

CalculateMaxCLL() 

{ 

set MaxCLL = 0 

for each (frame in the sequence ) 

{ 

set frameMaxLightLevel = 0 

for each ( pixel in the active image area of the frame ) 

{ 

convert the pixel’s non-linear (R’,G’,B') values to linear values (R,G,B) calibrated 
to cd/m 2 

set maxRGB = max(R,G,B) 
if(maxRGB>frameMaxLightLevel) 

set frameMaxLightLevel = maxRGB 

} 

if(frameMaxLightLevel>MaxCLL ) 

set MaxCLL = frameMaxLightLevel 

} 

return MaxCLL 

} 


P.2 MaxFALL 

CalculateMaxFALL() 

{ 

set MaxFALL = 0 

for each (frame in the sequence ) 

{ 

set runningSum = 0 

for each ( pixel in the active image area of the frame ) 

{ 

convert the pixel’s non-linear (R’,G’,B') values to linear values (R,G,B) calibrated 
to cd/m 2 

set maxRGB = max(R,G,B) 

set runningSum = runningSum + maxRGB 

} 

set frameAverageLightLevel = runningSum / numberOfPixelsInActivelmageArea 
if(frameAverageLightLevel>MaxFALL ) 

set MaxFALL = frameAverageLightLevel 

} 

return MaxFALL 

} 
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Annex Q Change in Audio Speaker Names from CTA-861-F to CTA-861-G (Informative) 

CTA-861 uses the speaker naming convention defined in ISO/IEC 62574 [42]. This Annex defines the 
relationship between the naming conventions used in CTA-861 versus previous revisions. Note that some 
positions defined are new and don’t have an equivalent position in previous versions of CTA-861. 


ISO/IEC 62574 and 
CTA-861-G Label 

Position Description 

CTA-861-F Label 

FL 

Front Left 

FL 

FR 

Front Right 

FR 

FC 

Front Center 

FC 

LFE1 

Low Frequency Effects 1 

LFE 

BL 

Back Left 


BR 

Back Right 


FLc 

Front Left of Center 

FLC 

FRc 

Front Right of Center 

FRC 

BC 

Back Center 

RC, RLC/RRC 23 I 

LFE2 

Low Frequency Effects 2 


SiL 

Side Left 


SiR 

Side Right 


TpFL 

Top Front Left 

FLH 24 

TpFR 

Top Front Right 

FRH 

TpFC 

Top Front Center 

TpFC 

TpC 

Top Center 

TC 

TpBL 

Top Back Left 


TpBR 

Top Back Right 


TpSiL 

Top Side Left 


TpSiR 

Top Side Right 


TpBC 

Top Back Center 


BtFC 

Bottom Front Center 


BtFL 

Bottom Front Left 


BtFR 

Bottom Front Right 


FLw 

Front Left Wide 

FLW 

FRw 

Front Right Wide 

FRW 

LS 

Left Surround 

RL 

RS 

Right Surround 

RR 

TpLS 

Top Left Surround 


TpRS 

Top Right Surround 



Rear Left of Center 

RLC 


Rear Right of Center 

RRC 


Table 143 Speaker Label Changes from CTA-861-F to CTA-861-G 


23 The split rear center is an artifact of the matrix surround era, where only a total of 4 channels existed, which were 
L, R, C, S. Some manufacturers in that brief era chose to array the S channel into two physical speakers, but with the 
same signal to each speaker. 

24 In IEC 62547 [42] labeling, Top Channels (Tp) are equivalent to Height (H) in various naming conventions. 
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Annex R HDR Dynamic Metadata Syntax Type 1 (Normative) 


R.1 Scope 


A display management (DM) message contains metadata in order to provide dynamic information that 
can be employed by the display to adapt the delivered HDR imagery to the capability of the display 
device. The information conveyed in this DM message corresponds to the metadata specified in SMPTE 
ST 2094-1 [56] and SMPTE ST 2094-10 [57], 

This annex specifies a syntax for the carriage of ST 2094-10 [57] Application #1 metadata for 
type_1_hdr_metadata_version value 0x0. This syntax is used for carriage of this metadata over the CTA- 
861 interface. It may also be used in an SEI message. Future versions of CTA-861 may specify the data 
format for future versions of type 1 metadata. 

R.2 Definitions 

Refer to ITU-T H.265 [55], Section 7.2 “Specification of syntax functions and descriptors” 


R.3 Display Management Message 

The data format for the DM message is defined in Table 144 DM_data(), Table 145 ext_dm_data_block(), 
and Table 146 ext_dm_data_block_payload(). 
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DM_data() { 

Descriptor 

reserved_1 

ue(v) 

reserved_2 

ue(v) 

reserved_3 

ue(v) 

reserved_4 

i(16) 

reserved_5 

i(16) 

reserved_6 

i(16) 

reserved_7 

i(16) 

reserved_8 

i(16) 

reserved_9 

i(16) 

reserved_10 

i(16) 

reserved_11 

i(16) 

reserved_12 

i(16) 

reserved_13 

u(32) 

reserved_14 

u(32) 

reserved_15 

u(32) 

reserved_16 

i(16) 

reserved_17 

i(16) 

reserved_18 

i(16) 

reserved_19 

i(16) 

reserved_20 

i(16) 

reserved_21 

i(16) 

reserved_22 

i(16) 

reserved_23 

i(16) 

reserved_24 

i(16) 

reserved_25 

u(16) 

reserved_26 

u(16) 

reserved_27 

u(16) 

reserved_28 

u(32) 

reserved_29 

u(5) 

reserved_30 

u(2) 

reserved_31 

u(2) 

reserved_32 

u(2) 

reserved_33 

u(12) 

reserved_34 

u(12) 

reserved_35 

u(10) 

num_ext_blocks 

ue(v) 

if( num_ext_blocks ) { 


while( !byte_aligned()) 


dm_alignment_zero_bit 

f(1) 

for( i = 0; i < num_ext_blocks; i ++ ) { 


ext dm data block() 


} 


} 


} 



Table 144 DM_data() 

reservecM - reserved_35 are not used. Sources shall set reserved_1 - reserved_35 to zero. Sinks 
shall ignore reserved_1 - reserved_35. 
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ext dm data block() { 

Descriptor 

ext block length 

ue(v) 

ext block level 

u(8) 

ext dm data block payload( ext block length, ext block level) 


I 



Table 145 ext_dm_data_block() 


ext dm data block payload( ext block length, ext block level) { 

Descriptor 

ext block len bits = 8 * ext block length 


ext block use bits = 0 


if( ext block level == 1 ) { 


min PQ 

u(12) 

max PQ 

u(12) 

avg PQ 

u(12) 

ext block use bits += 36 


I 


if( ext block level == 2 ) { 


target max PQ 

u(12) 

trim slope 

u (12) 

trim offset 

u(12) 

trim power 

u(12) 

trim chroma weight 

u(12) 

trim saturation gain 

u(12) 

ms weight 

if 13) 

ext block use bits += 85 


I 


iff ext block level == 3 ) { 


min PQ offset 

u(12) 

max PQ offset 

u(12) 

avg PQ offset 

u(12) 

ext block use bits += 36 


} 


iff ext block level == 5 ) { 


active area left offset 

u(13) 

active area right offset 

u(13) 

active area top offset 

u(13) 

active_area_bottom_offset 

u(13) 

ext block use bits += 52 


I 


whilef ext block use bits++ < ext block len bits ) 


ext dm alignment zero bit 

f(1) 

) 



Table 146 ext_dm_data_block_payload() 


num_ext_blocks specifies the number of extended metadata blocks. The value shall be in the range of 0 
to 254, inclusive. 

dm_alignment_zero_bit shall be equal to 0. dm_alignment_zero_bit is not present if num_ext_blocks is 
equal to 0. 

ext_block_length is used to derive the size of current extended metadata block payload in bytes. 
Ext_blockJength is not present if num_ext_blocks is equal to 0. 

ext_block_level specifies the level of payload contained in the current extended metadata block. The 
value shall be in the range of 0 to 255, inclusive. The corresponding block levels are defined in Table 147 
below. If ext_block_level is not present, it shall be inferred to be 0. 


202 





CTA-861-G 


ext_block_level 

extended metadata block type 

0 

Reserved 

1 

Level 1 Metadata - Content Range 

2 

Level 2 Metadata - Trim Pass 

3 

Level 3 Metadata - Content Range Offsets 

4 

Reserved 

5 

Level 5 Metadata - Active Area 

6...255 

Reserved 


Table 147 Definition of extended metadata block type 


If there is more than one extension block with ext_block_level equal to 1, decoder shall only use the latest 
level 1 extension block transmitted in current frame. If there are more than 16 extension blocks with 
ext_blockJevel equal to 2, decoder shall only use the first 16 level 2 extension blocks transmitted in 
current frame. If there is an extension block with ext_blockJevel equal to reserved values, decoder shall 
ignore that extension block. If there is no extension block transmitted in the current frame, the decoder 
shall fall back to the values of level 1 and level 2 extended metadata as specified below. 

min_PQ specifies the minimum luminance value of current scene in 12-bit PQ encoding. The value shall 
be in the range of 0 to 4095, inclusive. If min_PQ is not present, it shall be inferred to be equal to the 
value of source_min_PQ. Note that the 12-bit min_PQ value is calculated as follows: 

min_PQ = Clip3(0,4095, Floor(Min * 4096 + 0.5)), 
where Min is MinimumPqencodedMaxrgb as defined in section 6.1.3 of ST 2094-10 [57] 

max_PQ specifies the maximum luminance value of current scene in 12-bit PQ encoding. The value shall 
be in the range of 0 to 4095, inclusive. If max_PQ is not present, it shall be inferred to be equal to the 
value of source_max_PQ. Note that the 12-bit max_PQ value is calculated as follows: 

max_PQ = Clip3(0,4095, Floor(Max * 4096 + 0.5)), 
where Max is MaximumPqencodedMaxrgb as defined in section 6.1.5 of ST 2094-10 [57] 

avg_PQ specifies the midpoint luminance value of current scene in 12-bit PQ encoding. The value shall 
be in the range of 0 to 4095, inclusive. If avg_PQ is not present, it shall be inferred to be equal to the 
value of (source_min_PQ + source_max_PQ) / 2. Note that the 12-bit avg_PQ value is calculated as 
follows: 

avg_PQ = Clip3(0, 4095, Floor(Avg * 4096 + 0.5)), 
where Avg is AveragePqencodedMaxrgb as defined in section 6.1.4 of ST 2094-10 [57] 

target_max_PQ specifies the maximum luminance value of a target display in 12-bit PQ encoding. The 
value shall be in the range of 0 to 4095, inclusive. If target_max_PQ is not present, it shall be inferred to 
be equal to the value of source_max_PQ. The target_max_PQ is the PQ encoded value of 
TargetedSystemDisplayMaximumLuminance as defined in section 10.4 of ST 2094-1 [56]. 

Note: If there is more than one extension block with ext_block_level equal to 2, those blocks shall have 
no duplicated target_max_PQ. 

trim_slope specifies the slope metadata. The value shall be in the range of 0 to 4095, inclusive. If 
trim_slope is not present, it shall be inferred to be 2048. Note that the 12-bit slope value is calculated as 
follows: 

trim_slope = Clip3(0, 4095, Floor((S - 0.5) * 4096 + 0.5)), 
where S is the ToneMappingGain, as defined in section 6.2.3 of ST 2094-10 [57]. 

trim_offset specifies the offset metadata. The value shall be in the range of 0 to 4095, inclusive. If 
trim_offset is not present, it shall be inferred to be 2048. Note that the 12-bit offset value is calculated as 
follows: 

trim_offset = Clip3(0, 4095, Floor((O+0.5) * 4096+ 0.5)), 
where O is the ToneMappingOffset, as defined in section 6.2.2 of ST 2094-10 [57]. 
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trim_power specifies the power metadata. The value shall be in the range of 0 to 4095, inclusive. If 
trim_power is not present, it shall be inferred to be 2048. Note that the 12-bit power value is calculated as 
follows: 

trimjpower — Clip3(0, 4095, Floor((P - 0.5) * 4096+ 0.5)), 
where P is the ToneMappingGamma, as defined in section 6.2.4 of ST 2094-10 [57]. 

trim_chroma_weight specifies the chroma weight metadata. The value shall be in the range of 0 to 
4095, inclusive. If trim_chroma_weight is not present, it shall be inferred to be 2048. Note that the 12-bit 
chroma weight value is calculated as follows: 

trim_chromajveight — Clip3(0, 4095, Floor((CW+0.5) * 4096+ 0.5)), 
where CW is the ChromaCompensationWeight, as defined in section 6.4.1 of ST 2094-10 [57]. 
trim_saturation_gain specifies the saturation gain metadata. The value shall be in the range of 0 to 
4095, inclusive. If trim_saturatioin_gain is not present, it shall be inferred to be 2048. Note that the 12-bit 
saturation gain value is calculated as follows: 

trim_saturation_gain — Clip3(0, 4095, Floor((SG+0.5) * 4096+ 0.5)), 
where SG is the SaturationGain, as defined in section 6.3.2 of ST 2094-10 [57]. 

ms_weight specifies the multiscale weight metadata. The value shall be in the range of -1 to 4095, 
inclusive. If ms_weight is not present, it shall be inferred to be 2048. Note that the 12-bit multiscale weight 
value is calculated as follows: 

ms weight = Clip3(0,4095, Floor((MS+1.0) * 2048+ 0.5)), 
where MS is the ToneDetailFactor * 2.0 - 1.0, 
with ToneDetailFactor defined in section 6.4.2 of ST 2094-10 [57]. 

Note: If ms_weight is equal to -1, it means the multiscale weight value shall be overridden by the local 
settings. 

min_PQ_offset specifies the offset to the minimum luminance value of current scene in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If min_PQ_offset is not present, it shall 
be inferred to be equal to the default value 2048. Note that the 12-bit min_PQ_offset value is calculated 
as follows: 

min_PQ_offset = Clip3(0, 4095, Floor((Min_Offset + 0.5) * 4096 + 0.5)), 
where Min_Offset is MinimumPqencodedMaxrgbOffset as defined in section 6.1.6 of ST 2094-10 [57]. 

max_PQ_offset specifies the offset to the maximum luminance value of current scene in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If max_PQ_offset is not present, it shall 
be inferred to be equal to the default value 2048. Note that the 12-bit max_PQ_offset value is calculated 
as follows: 

max_PQ_offset = Clip3(0, 4095, Floor((Max_Offset + 0.5) * 4096 + 0.5)), 
where Max_Offset is MaximumPqencodedMaxrgbOffset as defined in section 6.1.8 of ST 2094-10 [57]. 

avg_PQ_offset specifies the offset to the midpoint luminance value of current scene in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If avg_PQ_offset is not present, it shall 
be inferred to be equal to the default value 2048. Note that the 12-bit avg_PQ_offset value is calculated 
as follows: 

avg_PQ_offset = Clip3(0, 4095, Floor((Avg_Offset + 0.5) * 4096 + 0.5)), 
where Avg_Offset is AveragePqencodedMaxrgbOffset as defined in section 6.1.7 of ST 2094-10 [57]. 

active_area_left_offset, active_area_right_offset, active_area_top_offset, 
active_area_bottom_offset specify the active area of current frame, in terms of a rectangular region 
specified in frame coordinates for active area. The values shall be in the range of 0 to 8191, inclusive. If 
active_area_left_offset, active_area_right_offset, active_area_top_offset, active_area_bottom_offset are 
not present, they shall be inferred to be 0. 

The coordinates of top left active pixel is derived as follows. 

Xtopjeft = active_area_left_offset 
Y topjeft = active_area_top_offset 
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The coordinates of top left active pixel are defined as the UpperLeftCorner in section 9.2 of ST 2094-1 
[56], 

The coordinates of bottom right active pixel is derived as follows. 

Xbottom right = XSize -1 - active_area_right_offset 
Ybottomjght = YSize -1 - active_area_bottom_offset 
Where Xbottomjght should be no smaller than Xtopjeft and Ybottom_right should be no smaller than Ytopjeft. 

The coordinates of bottom right active pixel are defined as the LowerRightCorner in section 9.3 of ST 
2094-1 [56], 

Note that XSize is the horizontal resolution of current frame and YSize is the vertical resolution of current 
frame. 

ext_dm_alignment_zero_bit shall be equal to 0. 
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Annex S HDR Dynamic Metadata Syntax Type 4 (Normative) 


5.1 Scope 

The SMPTE ST 2094 suite of documents defines metadata for use in color volume transforms of content. 
The metadata are content-dependent and can vary scene-by-scene or frame-by-frame. The metadata are 
intended to transform High Dynamic Range and Wide Color Gamut (HDR/WCG) source content for 
presentation on a display having a smaller color volume than the source content’s mastering display. 

SMPTE ST 2094-40 Application #4 [58] specifies the content-dependent color volume transform 
metadata items for Application #4. This color volume transform defines scene-based metadata to 
reproduce the original intent of the creator of High Dynamic Range (HDR) and Wider Color Gamut (WCG) 
image essence on a display having a smaller color volume, even in the case that the mastering display 
and the targeted system display may both have practical limits on the peak luminance they can produce. 

This annex specifies a syntax for the carriage of SMPTE ST 2094-40 Application #4 [58] metadata for 
type_4_hdr_metadata_version value 0x0. This syntax is used for carriage of this metadata over the CTA- 
861 interface. It may also be used in an SEI message. Future versions of CTA-861 may specify the 
syntax for future versions of type 4 metadata. 

5.2 User_data_registered_itu_t_t35 SEI message syntax for ST 2094-40 [58] 
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user_data_registered_itu_t_t35 () { 

Descriptor 

itu_t_t35_country_code 

u(8) 

itu_t_t35_terminal_provider_code 

u(16) 

itu_t_t35_terminal_provider_oriented_code 

u(16) 

application identifier 

u(8) 

application version 

u(8) 

num_windows 

u(2) 

for( w = 1; w < num_windows; w++ ) { 


window_upper_left _corner_x[ w ] 

u(16) 

window upper left corner y[ w 1 

u(16) 

window_lower_right_corner_x[ w ] 

u(16) 

window_lower_right_corner_y[ w ] 

u(16) 

center_of_ellipse_x[ w ] 

u(16) 

center_of_ellipse_y[ w ] 

u(16) 

rotation angle! w 1 

u(8) 

semimajor_axis_internal_ellipse[ w ] 

u(16) 

semimajor_axis_external_ellipse[ w ] 

u(16) 

semiminor_axis_external_ellipse[ w ] 

u(16) 

overlap process option! w 1 

u(1) 

} 


targeted_system_display_maximum_luminance 

u(27) 

targeted_system_display_actual_peak_luminance_flag 

u(1) 

if( targeted_system_display_actual_peak_luminance_flag ) { 


num rows targeted system display actual peak luminance 

u(5) 

num cols targeted system display actual peak luminance 

u(5) 

for( i = 0; i < num_rows_targeted_system_display_actual_peak_luminance; i++ ) 


for( j = 0; j < num cols targeted system display actual peak luminance; j++ 

) 


targeted system display actual peak luminance[ i ][ j ] 

u(4) 

} 


for( w = 0; w < num_windows; w++ ) { 


for( i = 0; i < 3; i++ ) 


maxscl[ w][i] 

u(17) 

average maxrgb! w 1 

u(17) 

num distribution maxrgb percentiles [ w 1 

u(4) 

for( i = 0; i < num_distribution_maxrgb_percentiles [ w ]; i++ ) { 


distribution_maxrgb_percentages[ w ][ i ] 

u(7) 

distribution maxrgb percentiles[ w ][ i ] 

u(17) 

} 


fraction bright pixels! w 1 

u(10) 

I 


mastering_display_actual_peak_luminance_flag 

u(1) 

if( mastering_display_actual_peak_luminance_flag ) { 


num rows mastering display actual peak luminance 

u(5) 

num cols mastering display actual peak luminance 

u(5) 

for( i = 0; i < num_rows_mastering_display_actual_peak_luminance; i++ ) 


for( j = 0; j < num_cols_mastering_display_actual_peak_luminance; j++ ) 


mastering display actual peak luminance! i ][j ] 

u(4) 

} 


for( w = 0; w < num windows; w++ ) { 


tone_mapping_flag[ w ] 

u(1) 

if( tone_mapping_flag ) { 


knee_point_x[ w ] 

u(12) 

knee point yf w 1 

u(12) 

num bezier curve anchors f w 1 

u(4) 

for( i = 0; i < num_bezier_curve_anchors [ w ]; i++ ) 


bezier curve anchors! w ][ i ] 

u(10) 

I 


color saturation mapping flagfwl 

_u(l)_ 
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if( color_saturation_mapping_flag) { 


color saturation weight[w] 

u(6) 

I 


) 


J_ 



Table 148 user_data_registered_itu_t_t35 


S.3 User_data_registered_itu_t_t35 SEI message semantics for ST 2094-40 [58] 

This SEI message provides information to enable color volume transformation of the reconstructed color 
samples of the output pictures. The input to the indicated color volume transform process is the linearized 
RGB color components of the source content. 

The information conveyed in this SEI message is intended to be adequate for purposes corresponding to 
the use of SMPTE ST 2094-40 [58], 

itu_t_t35_country_code shall be a byte having a value specified as a country code by Rec. ITU-T T.35 
Annex A [59]. The value shall be 0xB5. 

itu_t_t35_terminal_provider_code shall be a fixed 16-bitfield. The value shall be 0x003C. 

itu_t_t35_terminal_provider_oriented_code shall be a 16-bit code. The value shall be as specified in 
Table 149. Table 


itu_t_t35_terminal_provider_oriented_code 

Indicated value 

0x0000 

Unspecified 

0x0001 

ST 2094-40 [58] 

0x0002 - OxOOFF 

Reserved 


Table 149 Table Interpretation of the itu_t_t35_terminal_provider_oriented_code 

application identifier identifies an application and its defining document in ST-2094 suite. 
Applicationjdentifier shall be set to 4. 

application version specifies the application version in the application defining document in ST-2094 
suite. Application_version shall be set to 0. 

num_windows indicates the number of processing windows. The first processing window shall be for the 
entire picture. The value of num_windows shall be in the range of 1 to 3, inclusive. 

window_upper_left _corner_x[ w ] specifies the x coordinate of the top left pixel of the w-th processing 
window. The value of window_upper_left _corner_x[ w ] shall not exceed 65535. The value of 
window_upperJeft_corner_x[ 0 ] shall be 0. 

window_upper_left_corner_y[ w ] specifies the y coordinate of the top left pixel of the w-th processing 
window. The value of window_upper_left _corner_y[ w ] shall not exceed 65535. The value of 
window_upper_left_corner_y[ 0 ] shall be 0. 

window_lower_right_corner_x[ w ] specifies the x coordinate of the bottom right pixel of the w-th 
processing window. The value of windowJower_right_corner_x[ w ] shall not exceed 65535. The value of 
windowJower_right_corner_x[ 0 ] shall be (width of Picture - 1). 

window_lower_right_corner_y[ w ] specifies the y coordinate of the bottom pixel of the w-th processing 
window. The value of window_lower_right_corner_y[ w ] shall not exceed 65535. The value of 
windowJower_right_corner_y[ 0 ] shall be (height of Picture - 1). 
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center_of_ellipse_x[ w ] specifies the x coordinate of the center position of the concentric internal and 
external ellipses of the elliptical pixel selector in the w-th processing window. The value of 
center_of_ellipse_x[ w ] shall be in the range of 0 to (width of Picture - 1), inclusive and in multiples of 1 
pixel. 

center_of_ellipse_y[ w ] specifies the y coordinate of the center position of the concentric internal and 
external ellipses of the elliptical pixel selector in the w-th processing window. The value of 
center_of_ellipse_y[ w ] shall be in the range of 0 to (height of Picture - 1), inclusive and in multiples of 1 
pixel. 

rotation_angle[ w ] specifies the clockwise rotation angle in degree of arc with respect to the positive 
direction of the x-axis of the concentric internal and external ellipses of the elliptical pixel selector in the 
w-th processing window. The value of rotation_angle[ w ] shall be in the range of 0 to 180, inclusive and 
in multiples of 1. 

semimajor_axis_internal_ellipse[ w ] specifies the semi-major axis value of the internal ellipse of the 
elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semimajor_axis_internal_ellipse[ w ] shall be in the range of 1 to 65535, inclusive and in multiples of 1 
pixel. 

semimajor_axis_external_ellipse[ w ] specifies the semi-major axis value of the external ellipse of the 
elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semimajor_axis_external_ellipse[ w ] shall not be less than semimajor_axisJnternal_ellipse[ w ]. The 
value of semimajor_axis_external_ellipse[ w ] shall be in the range of 1 to 65535, inclusive and in 
multiples of 1 pixel. 

semiminor_axis_external_ellipse[ w ] specifies the semi-minor axis value of the external ellipse of the 
elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semiminor_axis_external_ellipse[ w ] shall be in the range of 1 to 65535, inclusive and in multiples of 1 
pixel. 

overlap_process_option[ w ] an enumerator that indicates one of the two methods of combining 
rendered pixels in the w-th processing window in an image with at least one elliptical pixel selector. For 
overlapping elliptical pixel selectors in an image, overlap_process_option[ w ] shall have the same value. 
overlap_process_option[ w ] = 0 shall indicate the Weighted Averaging method and 
overlap_process_option[ w ] = 1 shall indicate the Layering method as described in Annex B of reference 
[59]. 

targeted_system_display_maximum_luminance specifies the nominal maximum display luminance of 
the targeted system display, in units of 0.0001 candelas per square meter. The value of 
targeted_system_display_maximumjuminance shall be in the range of 0 to 10000, inclusive. 

targeted_system_display_actual_peakjuminance_flag, when present, shall be equal to 0 in 
metadata conforming to this version of this Specification. The value 1 for 

targeted_system_display_actual_peak_luminance_flag is reserved for future use by CTA. Decoders shall 
ignore the value of targeted_system_display_actual_peakjuminance_flag. 

num_rows_targeted_system_display_actual_peak_luminance specifies the number of rows in the 
targeted_system_display_actual_peakjuminance array. The value of 

num_rows_targeted_system_display_actual_peak_luminance shall be in the range of 2 to 25, inclusive. 

num_cols_targeted_system_display_actual_peakJuminance specifies the number of columns in the 
targeted_system_display_actual_peakjuminance array. The value of 

num_cols_targeted_system_display_actual_peakJuminance shall be in the range of 2 to 25, inclusive. 
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targeted_system_display_actual_peakjuminance[ i ][ j ] specifies the normalized actual peak 
luminance of the targeted system display. The value of 

targeted_system_display_actual_peakjuminance[ i ][j ] shall be in the range of 0 to 1, inclusive and in 
multiples of 1/15. 

maxsci[ w][i] specifies the maximum of the i-th color component of linearized RGB values in the w-th 
processing window in the scene. The value of maxscl[ w ][ i ] shall be in the range of 0 to 1, inclusive and 
in multiples of 0.00001. maxscl[ w ][ 0 ], maxscl[ w ][ 1 ], and maxscl[ w ][ 2 ] are corresponding to R, G, B 
color components respectively. 

average_maxrgb[ w ] specifies the average of linearized maxRGB values in the w-th processing window 
in the scene. The value of average_maxrgb[ w ] shall be in the range of 0 to 1, inclusive and in multiples 
of 0.00001. 

num_distribution_maxrgb_percentiles [ w ] indicates the number of linearized maxRGB values at 
given percentiles in the w-th processing window in the scene. The maximum value of 
num_distribution_maxrgb_percentiles [ w] shall be 15. 

distribution_maxrgb_percentages[ w ][ i ] specifies an integer percentage value corresponding to the i- 
th percentile linearized RGB value in the w-th processing window in the scene. The value of 
distribution_maxrgb_percentages[ w ][ i ] shall be in the range of 0 tol 00, inclusive. 

distribution_maxrgb_percentiles[ w ][ i ] specifies the linearized maxRGB value at the i-th percentile in 
the w-th processing window in the scene. The value of distribution_maxrgb_percentiles[ w ][ i ] shall be in 
the range of 0 to 1, inclusive and in multiples of 0.00001. 

fraction_bright_pixels[ w ] specifies the fraction of selected pixels in the image that contains the 
brightest pixel in the scene. The value of fraction_bright_pixels[ w ] shall be in the range of 0 to 1, 
inclusive and in multiples of 0.001. 

mastering_display_actual_peak_luminance_flag, when present, shall be equal to 0 in metadata 
conforming to this version of this Specification. The value 1 for 

mastering_display_actual_peakjuminance_flag is reserved for future use by CTA. Decoders shall ignore 
the value of mastering_display_actual_peakjuminance_flag. 

num_rows_mastering_display_actual_peak_luminance specifies the number of rows in the 
mastering_display_actual_peakjuminance array. The value of 

num_rows_mastering_display_actual_peakJuminance shall be in the range of 2 to 25, inclusive. 

num_cols_mastering_display_actual_peak_luminance specifies the number of columns in the 
mastering_display_actual_peakjuminance array. The value of 

num_cols_mastering_display_actual_peakJuminance shall be in the range of 2 to 25, inclusive. 

mastering_display_actual_peak_luminance[ i ][ j ] specifies the normalized actual peak luminance of 
the mastering display used for mastering the image essence. The value of 

mastering_display_actual_peakjuminance[ i ][ j ] shall be in the range of 0 to 1, inclusive and in multiples 
of 1/15. 

tone_mapping_flag[ w ] equal to 1 indicates that the metadata for the tone mapping function in the w-th 
processing window is present. 

knee_point_x[ w ] specifies the x coordinate of the separation point between the linear part and the 
curved part of the tone mapping function. The value of knee_point_x[ w ][ i ] shall be in the range of 0 to 
1, excluding 0 and in multiples of 1/4095. 
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knee_point_y[ w ] specifies the y coordinate of the separation point between the linear part and the 
curved part of the tone mapping function. The value of knee_point_y[ w ][ i ] shall be in the range of 0 to 
1, excluding 0 and in multiples of 1/4095. 

num_bezier_curve_anchors [ w ] indicates the number of the intermediate anchor parameters of the 
tone mapping function in the w-th processing window. The maximim value of num_bezier_curve_anchors 
[ w ] shall be 15. 

bezier_curve_anchors[ w ][ i ] 

specifies the i-th intermediate anchor parameter of the tone mapping function in the w-th processing 
window in the scene. The value of bezier_curve_anchors[ w ][ i ] shall be in the range of 0 to 1, inclusive 
and in multiples of 1/1023. 

color_saturation_mapping_flag[ w ] shall be equal to 0 in bitstreams conforming to this version of this 
Specification. Other values for color_saturation_mapping_flag[ w ] are reserved for future use by CTA. 
Decoders shall ignore the value of color_saturation_mapping_flag[ w ]. 

color_saturation_weight[ w ] specifies a number that shall adjust the color saturation gain in the w-th 
processing window in the scene. The value of color_saturation_weight[ w ] shall be in the range of 0 to 
63/8, inclusive and in multiples of 1/8. The default value shall be 1. 

Note: Definitions of the metadata items and terms used in this section of the document are provided in 
reference [56] and [58]. A color volume transform method using this message is described in Annex B of 
reference [58]. 
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